Re: validator_list still in docs
On Mon, Aug 25, 2008 at 6:57 PM, Michael Hrivnak <[EMAIL PROTECTED]> wrote: > That is neither a direct nor indirect replacement for model-level validation. > Many applications receive input from sources other than forms. Validation at > the form and model level are both valuable, but for different reasons. True, but Django has *never* supported model-level validation; validator_list has always only been a shortcut for specifying some validation logic that shows up in automatically-generated forms. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
old docs not opening
http://www.djangoproject.com/documentation/0.96/pagination/ Giving 404. Known issue or I should file a bug? -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: old docs not opening
On Tue, Aug 26, 2008 at 4:58 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > Giving 404. Known issue or I should file a bug? Due to limitations of the old docs system, there are quite a few such links (typically due to documentation which existed in one release but not in another). There's no need for a ticket. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Beef with Django; admin and auth
I'm quite new to django, so I'm not sure where to put that patch. I tried it in settings.py and urls.py but it didn't affect anything. Where's the correct place to put it? Thanks On Aug 15, 1:14 am, Julien Phalip <[EMAIL PROTECTED]> wrote: > Hi, > > So far I haven't had too much trouble customizing the authentication > system. However, I've stumbled one important problem: it doesn't > appear to be possible to authenticate with usernames longer than 30 > characters, which is a serious issue if you want to login with your > email address for example. > > This is caused by the login view being bound to use the standard > `AuthenticateForm`. Even if using a custom authentication backend, > this problem is a stopper. Unless you fork your own version of the > login view (yuk!), or do a nasty one-line monkey patch like: > > AuthenticationForm.base_fields['username'].max_length = 75 > > I've posted a ticket about this with a simple > patch:http://code.djangoproject.com/ticket/8274 > > I really hope it gets in. If I've missed something here, please let me > know the right way to approach this. > > Cheers, > > Julien --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
request_started signal
Is seems that request_started & request_finished are used by the db to manage connections, so I would expect it to work as defined. I have some code for processing the urlsconf so signals seems like the obvious tool. Apparently there is on server_started signal firing when configuration is complete(that would be a very nice signal to get into 1.0), so I try to use request_started. from django.core import urlresolvers from django.core.signals import request_started def build_rules(**kwargs): request_started.disconnect(build_rules) resolver = urlresolvers.get_resolver(None) print "BUILD RULES" for url in resolver.url_patterns: print url.pattern request_started.connect(build_rules) I would expect BUILD RULES to be called once before the first request processing. Instead I get this output: Django version 1.0-alpha-SVN-unknown, using settings 'conf.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C. [26/Aug/2008 13:23:48] "GET /retail/collection HTTP/1.0" 200 5790 BUILD RULES ^$ ^admin/(.*) [26/Aug/2008 13:24:06] "GET /retail/collection HTTP/1.0" 200 5790 Could this be a bug that need to be weeded out or am I doing something wrong? Henrik I'm on: git-svn-id: http://code.djangoproject.com/svn/django/[EMAIL PROTECTED] bcc190cf-cafb-0310-a4f2-bffc1f526a37 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: request_started signal
On Tue, Aug 26, 2008 at 8:05 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I have some code for processing the urlsconf so signals seems like the > obvious tool. Apparently there is on server_started signal firing when > configuration is complete(that would be a very nice signal to get into > 1.0), so I try to use request_started. I think you're running into conceptual problems with both the "request_started" signal, and the architecture of Django itself. The "request_started" signal simply means "an HTTP request has come in, and processing of that request is beginning". As such, it fires on *every* HTTP request/response cycle. So any function listening for that signal will also execute on *every* HTTP request/response cycle. Speaking more broadly, there's really no concept of "server started" in Django, because Django stays fairly close to the nature of HTTP -- a stateless protocol built around request/response cycles. For some notes on that and how to work with it, see this blog entry: http://www.b-list.org/weblog/2007/nov/05/server-startup/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: request_started signal
Thanks for the reply. You are of course right. I should just do my processing of urlconf whenever when it is needed, and leave caching to some future optimisation. Even so; Given your definition of the signal, how come the BUILD_RULES is output after the request log line, is that just a property of the print statement? Btw, I couldn't agree more on the importance of adhering to the letter and spirit of HTTP. The whole RESTful approach makes perfect sense to me. On Aug 26, 2:38 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On Tue, Aug 26, 2008 at 8:05 AM, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > > I have some code for processing the urlsconf so signals seems like the > > obvious tool. Apparently there is on server_started signal firing when > > configuration is complete(that would be a very nice signal to get into > > 1.0), so I try to use request_started. > > I think you're running into conceptual problems with both the > "request_started" signal, and the architecture of Django itself. > > The "request_started" signal simply means "an HTTP request has come > in, and processing of that request is beginning". As such, it fires on > *every* HTTP request/response cycle. So any function listening for > that signal will also execute on *every* HTTP request/response cycle. > > Speaking more broadly, there's really no concept of "server started" > in Django, because Django stays fairly close to the nature of HTTP -- > a stateless protocol built around request/response cycles. For some > notes on that and how to work with it, see this blog entry: > > http://www.b-list.org/weblog/2007/nov/05/server-startup/ > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers
On Sun, Aug 24, 2008 at 10:24 AM, Jacob Kaplan-Moss < [EMAIL PROTECTED]> wrote: > > Quick note: Malcolm and I are in Portland in the only place in the > city sans wifi. We've talked about this and the other exc swallowing > issue and I have some thoughts. Please hold until I'm in a more > civilized location and can actually use a keyboard bigger than a few > stamps. > So it's a couple of days later...got time to update with your thoughts? I'm not trying to be a pain, I just spent some time investigating #8569 where this exception-swallowing behavior completely obscures the real origin of the error (which is obscure enough with the actual traceback). I know how to get rid of it so it wasn't any big deal for me to patch the code to remove the exception swallowing, but I fear if 1.0 ships like this we'll be getting a lot of reports of ImproperlyConfigured exceptions with tantalizingly vague error messages and no real traceback informaiton to be able to guide people as to whether it's a bug in their code or a bug in Django. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers
On Tue, Aug 26, 2008 at 3:38 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > So it's a couple of days later...got time to update with your thoughts? Yeah, I'm sorry; I lost track of this. Essentially I think that James is right that a systematic fix would be better, but I don't see what that might look like. Unfortunately, I'm really not sure exactly what we can do -- there's some places where perhaps we could not raise ImproperlyConfigured, but the problem is that sometimes those messages are *more* helpful, and other times less. It's not entirely clear (to me) what a fix, even a half-assed one, would look like I started going down the path of having ImproperlyConfigured take an ``original_exception`` argument and displaying that original exception from manage.py, but that's pretty fiddly. So I think we need to do something along the lines of what's in #7524... it's far, far from perfect, but it's probably the only way to go to avoid a lot of frustration. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers
On Tue, Aug 26, 2008 at 4:55 PM, Jacob Kaplan-Moss < [EMAIL PROTECTED]> wrote: > So I think we need to do something along the lines of what's in > #7524... it's far, far from perfect, but it's probably the only way to > go to avoid a lot of frustration. > > So should #7524 get moved back to a 1.0 milestone? FWIW it is the 2nd patch on that ticket I used to enable me to see what was the real issue with the problem I was looking at earlier today, and that ticket has at least 2 dups with nearly identical patches, so that particular case of wrapping the original exception in ImproperlyConfigured does seem to be causing a fair number of headaches. Doing something to address it, alone, before 1.0 ships would be a good idea, IMO. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: what's wrong with the djangoadmin tool of mine
Please ask usage questions on django-users, not here. This list is for discussion of developing Django itself, not using it. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
contrib.auth tests
contrib.auth view tests fail if required templates aren't found. This seems a sensible default in line with Russell's post [1] but rev 8497 introduces a test only template directory [2] which a) causes the tests to pass in the absence of an actual login template (the provided template is not a default template, it's a test template); and b) overwrites the TEMPLATE_DIRS so that any user provided templates must be in an app template directory. This is the case where contrib.admin is installed. #8523 has a patch with removes the overwriting of the TEMPLATE_DIRS with a test only template dir, restoring the previously default desired behavior but it was marked wontfix. I added a patch which prepended the test template dir to settings.TEMPLATE_DIRS, but the original patch is probably correct if we agree that the view tests should fail if required templates aren't found. If this isn't the case, contrib.auth should provide default templates rather than test only templates and testing user supplied templates ought be the responsibility of the user. Thoughts? 1. http://groups.google.com/group/django-developers/msg/e7c9ec81b209e01e 2. http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/tests/views.py?rev=8497#L97 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib.auth tests
On Tue, 2008-08-26 at 18:09 -0700, Cam MacRae wrote: > contrib.auth view tests fail if required templates aren't found. This > seems a sensible default in line with Russell's post [1] The problem with that original position is that it overloads testing to include both testing the auth app's implementation and testing the user's configuration when they're using the auth app. So there are definitely two legitimate sides to that opinion. I much prefer self-contained unittests. I read Russell's mail as preferring to trade that for installation/configuration testing. I don't particularly agree with that, but I could live with it if we decide it's the way we want to go. > but rev 8497 > introduces a test only template directory [2] which > > a) causes the tests to pass in the absence of an actual login template > (the provided template is not a default template, it's a test > template); It also means the tests pass as a self-contained bundle to test the auth app, rather than requiring a user using the auth app to have to set up all these templates even if they're not using a particular piece of the auth app just to have the tests pass. That's not a trivial concern. There is a middle ground here, which is that those auth-app templates get moved to the Django's main test directory so that they're available only to runtests. That doesn't feel particularly self-contained and again, for me, violates the intuitive meaning of the word unittest, but it's the way we've gone with the new comment tests and the admin tests, for example. Might be a trend to follow. Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib.auth tests
On Aug 27, 11:20 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I much prefer self-contained unittests. I read Russell's mail as > preferring to trade that for installation/configuration testing. I don't > particularly agree with that, but I could live with it if we decide it's > the way we want to go. I disagree also, but from reading here and on the various tickets where it's come up it seemed to have been decided. If there is room to move, I think that contrib apps should be self contained for test purposes. > It also means the tests pass as a self-contained bundle to test the auth > app, rather than requiring a user using the auth app to have to set up > all these templates even if they're not using a particular piece of the > auth app just to have the tests pass. That's not a trivial concern. Agree it's not a trivial concern. > > There is a middle ground here, which is that those auth-app templates > get moved to the Django's main test directory so that they're available > only to runtests. That doesn't feel particularly self-contained and > again, for me, violates the intuitive meaning of the word unittest, but > it's the way we've gone with the new comment tests and the admin tests, > for example. Might be a trend to follow. Where test templates are available only to runtests, is it true to say that anyone not using the contrib.auth views still needs to provide the templates in their project? Rather than test specific templates, why not provide a set of default app templates? By doing so, the app is self contained, anyone not using the views can forget the tests, anyone who is using them has the freedom to use their own templates and the comfort that those templates will be used for the tests. cam. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib.auth tests
On Aug 26, 6:51 pm, Cam MacRae <[EMAIL PROTECTED]> wrote: > Rather than test specific templates, why not provide a set of default > app templates? By doing so, the app is self contained, anyone not > using the views can forget the tests, anyone who is using them has the > freedom to use their own templates and the comfort that those > templates will be used for the tests. I think part of it is that the auth module provides a lot of very useful data without specifying the "registration" stuff. I use contrib.auth without requiring passwords which invalidates a ton of urls hooked into contrib.auth.urls - this means that all the tests fail. I would definitely prefer having self contained templates for contrib.auth tests - I realize that if templates are to be included by the users then it's great to have them automatically tested, but there's so much functionality that can be had without requiring these urls and views. In other words, my vote is to set up fake templates for the testing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib.auth tests
On Aug 27, 1:42 pm, Michael Richardson <[EMAIL PROTECTED]> wrote: > I use > contrib.auth without requiring passwords which invalidates a ton of > urls hooked into contrib.auth.urls - this means that all the tests > fail. In this case they'd fail irrespective of the templates, no? > I would definitely prefer having self contained templates for > contrib.auth tests*snip* > > In other words, my vote is to set up fake templates for the testing. So if I understand it, to remove the current test dependency on contrib.admin our options include: We use test templates and keep them in the module, so we get self contained tests at the expense of the user having to write their own tests for contrib.auth views iff they use them. I guess that applies to contrib.admin too. This is closest to what we have right now (post rev 8497) with the advantage that users without contrib.admin installed will have their project tests pass without having to create an empty app for auth templates. We use test templates and keep them in Django's main test directory. contrib.admin will still require it's own auth view tests the contrib.auth tests will no longer function as integration tests for admin, and users without contrib.admin installed will still need to supply the templates for their project tests to pass. We use default app templates and keep them in the module, so get self contained tests which also cover user supplied templates (albeit where EN copy changes require translation), but we lose the behavior where the tests fail without a user supplied template. I'll gladly do the work if we can come to decision as to which path to follow. cheers, Cam. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib.auth tests
On Aug 27, 1:42 pm, Michael Richardson <[EMAIL PROTECTED]> wrote: > I use > contrib.auth without requiring passwords which invalidates a ton of > urls hooked into contrib.auth.urls - this means that all the tests > fail. In this case they'd fail irrespective of the templates, no? > I would definitely prefer having self contained templates for > contrib.auth tests*snip* > In other words, my vote is to set up fake templates for the testing. So if I understand it our options include: We use test templates and keep them in the module: We get self contained tests at the expense of the user having to write their own tests for contrib.auth views iff they use them. I guess that applies to contrib.admin too. This is closest to what we have right now (post rev 8497) with the advantage that users without contrib.admin installed will have their project tests pass without having to create an empty app for auth templates. We use test templates and keep them in Django's main test directory. contrib.admin will still require it's own auth view tests as the contrib.auth tests will no longer function as integration tests for admin, and users without contrib.admin installed will still need to supply the templates for their project tests to pass. We use default app templates and keep them in the module: we get self contained tests which also cover user supplied templates (albeit where EN copy changes require translation), but we lose the behavior where the tests fail without a user supplied template. I'll gladly do the work if we can come to decision as to which path to follow. cheers, Cam. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
