Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
On Oct 27, 1:46 pm, mrts <[EMAIL PROTECTED]> wrote: > > IMHO this should be documented, so I > > reopenedhttp://code.djangoproject.com/ticket/9409 > > and changed the component to Documentation. > > I've attached the explanation > tohttp://code.djangoproject.com/attachment/ticket/9409/database_is_lock... I agree, and this explanation looks good. +1 --~--~-~--~~~---~--~~ 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: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
On Oct 21, 7:27 am, mrts <[EMAIL PROTECTED]> wrote:
> It seems that current DB lock management doesn't play nice with the
> new Python 2.6 multiprocessing package and SQLite. See [1]. The same
> error also popped up in Google search under mod_python [2].
As others have pointed out, this isn't an issue with Django. The
easiest solution is to make this error less common with a higher
timeout. In settings.py:
DATABASE_OPTIONS = {'timeout': 30}
--~--~-~--~~~---~--~~
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: auto_now_add and auto_now
On Oct 13, 11:15 am, Brian Beck <[EMAIL PROTECTED]> wrote: > The only action was three months ago with a DeprecationWarning patch that > isn't checked in. ...and probably shouldn't be, since it still doesn't update the docs. --~--~-~--~~~---~--~~ 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: auto_now_add and auto_now
On Oct 13, 8:38 am, "Mike Scott" <[EMAIL PROTECTED]> wrote: > Secondly this question has been asked, and solved many times. If you search > through the django-users archives I'm sure you'll find plenty of solutions. > There are solutions out and about in the blogosphere too. Actually I think this is an appropriate place to ask since the resolution (which was unclear) never resulted in action. I was confused about these myself just yesterday because the documentation doesn't mention anything about possible future deprecation. The only action was three months ago with a DeprecationWarning patch that isn't checked in. --~--~-~--~~~---~--~~ 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: Proposal: django.forms.SafeForm - forms with built in CSRF protection
On Sep 25, 2:54 am, Rudolph <[EMAIL PROTECTED]> wrote: > I like Luke's arguments. > > A middleware seems like the right place because CSRF protection is > about requests and responses. CSRF protection is more about POST > requests in generic, with HTML forms being a very common type of POST > request. > > IMHO the default settings.py file (generated with 'django-admin.py > startproject') should have the middleware enabled by default. I wouldn't mind keeping the middleware around and enabling it by default, but including SafeForm in the same app (at django.contrib.csrf.forms). --~--~-~--~~~---~--~~ 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: Running tests.py in apps without models.py
On Sep 23, 3:40 pm, "Adam J. Forster" <[EMAIL PROTECTED]> wrote: > Hi Eric, > > That's what I have done at the moment, but as you say it's a bit of a > hack and I'm not sure that I'm happy with it. I ran across this bug the other day too; quite annoying. It's ticket #3310 and there appears to be a patch. --~--~-~--~~~---~--~~ 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: Proposal: django.forms.SafeForm - forms with built in CSRF protection
On Sep 23, 10:56 am, oggie rob <[EMAIL PROTECTED]> wrote: > I'm sorry, I used the wrong term here. I didn't mean that CSRF > protection isn't worthwhile, just that going the route of an extended > form might not be the best way to do it. > As for suggestions, I'm not sure I have one exactly, but I'm thinking > of perhaps overriding is_valid() and maybe using the RequestContext > object.. not sure yet. The problem is that any token, no matter where we generate it, isn't going to be submitted back with the POST request unless it's a field in the form that was submitted. So the only options I see are mangling the HTML to add these fields (CsrfMiddleware), or add them to the form objects (SafeForm). --~--~-~--~~~---~--~~ 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: Proposal: django.forms.SafeForm - forms with built in CSRF protection
On Sep 22, 5:16 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > One thing that might help out in this case would be the ability to > create a SafeForm from a regular Form (which might be an argument for > csrf protection as a feature of django.forms.Form rather than a > subclass). If the third party code is well written (it follows the > class-based generic view idiom for example, providing a get_form() > method that can be over-ridden) it should be straight forward to > intercept the form it creates and upgrade it to a SafeForm. See my previous post I just slipped in while you were replying. :) --~--~-~--~~~---~--~~ 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: Proposal: django.forms.SafeForm - forms with built in CSRF protection
On Sep 22, 5:01 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > But still, the situation dictates the need for SafeForm, not the form > author. If this becomes best practice, essentially *every* form will > need to be initialized with a request. What about something like: def protect_form(form_class): class SafeForm(form_class): csrf_token = CharField(...) def clean_csrf_token(self): ... return SafeForm protect_form(ThirdPartyForm)(request.POST, request=request) --~--~-~--~~~---~--~~ 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: Proposal: django.forms.SafeForm - forms with built in CSRF protection
On Sep 22, 4:55 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > > -- What about third-party app forms that aren't SafeForms, but need to > > be? The situation dictates this, not the form author. > I think we keep CSRF middleware around to deal with that. We also very > actively encourage third party apps to adopt SafeForm as soon as 1.1 > is out. But still, the situation dictates the need for SafeForm, not the form author. If this becomes best practice, essentially *every* form will need to be initialized with a request. P.S. I just posted the code I was using if anyone is interested: http://www.djangosnippets.org/snippets/1077/ --~--~-~--~~~---~--~~ 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: Proposal: django.forms.SafeForm - forms with built in CSRF protection
On Sep 22, 4:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm willing to bet most people don't turn it on.
+0.5, I've written almost the exact code for this in a project for a
client. I would be +1 if:
- CsrfMiddleware was marked as deprecated. You're right; it's ugly.
However:
-- What about third-party app forms that aren't SafeForms, but need to
be? The situation dictates this, not the form author.
- If there's some other way to spell form.protect(response).
-- What about situations where the developer does not have access to
the response; if the form is loaded from a template tag or filter, for
instance: {% with model_obj|get_the_right_form as obj_form %} (I know,
you probably don't recommend this ;)
--~--~-~--~~~---~--~~
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: Proposal: label tag attributes
On Sep 15, 8:50 am, "Eduardo O. Padoan" <[EMAIL PROTECTED]>
wrote:
> On Mon, Sep 15, 2008 at 9:39 AM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> > That's a good point. Mixing {% include %} and {% with %} is both more
> > verbose and less flexible than if using a custom tag. In this case,
> > using a custom filter would also make sense since it's about
> > presentation:
>
> > {{ form|render_form:"thisway" }}
>
> I tend to see filters more as a way to format text, and inclusion_tags
> looks more like function calls:
>
> {% show_fields comment_form %}
I've long been of the opinion that this is the way to go for form
rendering. The problem is that it's not easy to tell the inclusion
tag to use a different template, for those who want to customize. And
as Simon points out, it's not immediately obvious where the actually
HTML is pulled from. However:
- Any template can be globally overridden - all you need to know is
the name
- Ticket 9093[1] will greatly improve this situation
Since I was doing it this way for a large project, I already had the
code written, so I cleaned it up and released it as django-
renderform[2]. I think this approach has a much more appealing future
than as_p, as_ul, as_table and such, especially if #9093 makes it in.
[1]: http://code.djangoproject.com/ticket/9093
[2]: http://code.google.com/p/django-renderform/
--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps
On Sep 20, 6:58 am, Erik Allik <[EMAIL PROTECTED]> wrote: > Has anyone got some good use cases where the template-loaded mimicking > behavior would be desired? Otherwise it's just needless complexity in > my opinion. Well, first of all, it's not really complexity at all. If it were to just copy all the media files found, the last app in INSTALLED_APPS would overwrite the others with the same name. This way, the first app in INSTALLED_APPS wins instead of the last one. That's the only difference. And the use case is of course to customize the style of a reusable app without modifying the actual files distributed with the app (which would make it a pain when upgrading). batchadmin[1], for example -- if you want to change the style of the batch action form, like to make it pink, just provide a file in your app named media/css/ batchadmin.css, just like you would provide a template at templates/ batchadmin/actions.html if you wanted to change the markup. [1]: http://code.google.com/p/django-batchadmin/ --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 19, 4:26 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > I also have an implementation that I'll post when I get home. I just posted my collectmedia (I liked the name Rajeev used) command here: http://www.djangosnippets.org/snippets/1068/ It's a long snippet because it includes an interactive mode and sets permissions (see below). For testing, I recommend running with -i and -n (interactive mode and dry run mode, respectively). I've tested it, but you should probably back up your media first. Features: If multiple apps provide a media file of the same name, use the file provided by the app listed first in INSTALLED_APPS - this mimics the template loader behavior. In interactive mode (-i), you may specify which app to select from for each such file. With this command, best practice would be to put media files at app/media/appname/... - just like templates. It attempts to be "smart" about permissions by using MEDIA_ROOT's permissions and ownership on all the files it creates. So, if MEDIA_ROOT is owned by apache/www-data for instance, the media files should, too. You may provide a directory other than MEDIA_ROOT to copy to. You may also use symbolic links instead of copying, but this doesn't work on Windows, so copying is the default behavior. See the code for the other options... Thoughts? --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
I noticed that elwaywitvac just posted this management command here: http://www.djangosnippets.org/snippets/1066/ I also have an implementation that I'll post when I get home. --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
wrote:
> A problem would be referencing images, and media in css/js files.
> Currently, in all our projects we use /site_media/ as the MEDIA_URL,
> so this not a problem. But for a true solution, there should be a
> preprocessor for css/js to use the MEDIA_URL within it.
CSS can refer to images by their path relative to the CSS file, so if
your media tree looks like:
media/css/base.css
media/images/icon.png
Then base.css can do: background-image('../images/icon.png')
...so no preprocessing needed there. But referring to *another app's*
images is another story. And JavaScript... well, don't reference
images in JavaScript.
> Another problem which we havent solved, is overrides. E.g., when we
> use a "plugabble"/reusable app with its own media, and we want to
> override this in our project, how should the collect media command
> work ?
I imagined this working just like templates. By *convention* apps can
lay out their media directories like media/appname. So there's
nothing stopping your app from including, say, media/anotherapp/css/
base.css, and we can say that whichever app is in INSTALLED_APPS first
wins, just like with templates.
--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > I really like the idea. However, I think there should also be a way to > configure it to not copy to MEDIA_ROOT but to somewhere else. Sure - a --destination flag, defaulting to MEDIA_ROOT, would work. > Also, instead of just copying the media files, it should also do some > cleanup. Say, if you're tracking trunk for a given app, when you SVN > update that app you want stale media files to be removed. This is getting into package management system territory ;) -- this problem is mostly solved by linking a directory instead of copying all the files, which I think should be the default behavior (linking, not copying). --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > Serving is totally orthogonal -- everyone is already serving up > MEDIA_ROOT in their projects somehow anyway, and this just copies > files to MEDIA_ROOT. Sorry, I guess that's not totally true -- everyone who uses more than just the admin app has set up static file serving for MEDIA_ROOT. --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 6:29 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > > Could it be a little smarter, and in the absence of specific apps, iterate > > over all INSTALLED_APPS, and install their media automagically? > > +1 for some sort of media.autodiscover(). > It would have to be optional though, as that might break backwards- > compatibility. I think he meant making "python manage.py installmedia" (no app names provided) install media for all INSTALLED_APPS, not something that will happen without running any commands -- so no backwards- compatibility will be affected. And I agree with Don's idea. > Also, there's an issue about the way files are served. For example, in > my projects I make Apache serve 'admin_media' files independently. > What would be an approach to make that serving configuration happen > for custom apps? Serving is totally orthogonal -- everyone is already serving up MEDIA_ROOT in their projects somehow anyway, and this just copies files to MEDIA_ROOT. --~--~-~--~~~---~--~~ 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: RFC: django.template refactoring (#7806)
On Sep 16, 2:36 pm, Johannes Dollinger <[EMAIL PROTECTED]> wrote: > Why should django.template be refactored? Filter and Variable parsing > is inconsistent. Many ad hoc parsers in defaulttags are fragile. > Whitespace handling is ungraceful. > > The patch provided in #7806[1] splits __init__.py into separate > modules[2] and introduces a TokenStream class that allows parsing of > literals, vars (called lookups) and filter expressions. Regardless of how it happens, I did notice when writing a patch for #9093 that django.template really could use some refactoring. +1 --~--~-~--~~~---~--~~ 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: Proposal for 1.1: Extend inclusion tag syntax to allow custom templates (#9093)
On Sep 16, 8:37 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote: > I don't think anyone will complain that they have to type less, as its > still understandable. +1 for allow_override. Changed to allow_override. See patch #4 at: http://code.djangoproject.com/ticket/9093 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: installmedia command - A story for distributing media with apps
Distributing media with apps could be a lot easier. Currently this requires copying or linking files manually (possibly each time the app is updated), and this encourages developers to put CSS and JavaScript inline in their templates. I propose a management command to make this easier: $ python manage.py installmedia appname [appname ...] The command is "dumb." It goes like this: - Read MEDIA_ROOT from settings.py. - Look for a 'media' directory in the app. - Copy or link everything in there to MEDIA_ROOT. This simple command saves you quite a bit of typing. Some possibilities... - Switches like --copy, --link, --overwrite, etc. - Just like with templates, it could become best practice for apps to have their media structured like so: media/ media/appname/ media/appname/css/ ... - Or in the simple case: media/ media/css/appname.css media/css/appname.js This should make it easier for apps to make assumptions about where their media is located relative to MEDIA_URL (this is currently ad hoc). Thoughts? --~--~-~--~~~---~--~~ 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: Improve Error Handlers
On Apr 12, 9:42 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On Fri, Apr 11, 2008 at 3:29 PM, Brian Beck <[EMAIL PROTECTED]> wrote: > > (Replying to myself.) Looking at the code I see they're just urlconf > > module globals. I assume they only take effect in ROOT_URLCONF? > > Documentation here: > > http://www.djangoproject.com/documentation/url_dispatch/#handler404http://www.djangoproject.com/documentation/url_dispatch/#handler500 That's the page I was referring to. It would really help if it mentioned that those are urlconf module globals under each one. All it says is that they're strings... --~--~-~--~~~---~--~~ 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: Proposal: Form rendering with filters
On Mar 18, 5:45 pm, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote:
> I have been pretty unhappy about the way html has been generated from
> newforms for awhile now. I think we've come up with a good design that
> makes form rendering a lot easier, and a lot more modular. The basic
> idea is to renderforms, formsets, errors, etc. with filters. Here are
> a few examples:
>
> {% load forms %}
> ...
Has anyone started working on this? I don't see a branch, but I'd
love to help out. I've also been writing similar tags and filters for
my form rendering (see [1]). I definitely agree with using tags
instead of filters due to their flexibility. Unlike the current
situation I hope these would render using the, *ahem*, templating
system? You know that thing for HTML generation and such? Then
people can really bust out the customization with their own widget/
label/form templates.
[1]: http://www.djangosnippets.org/snippets/693/
--~--~-~--~~~---~--~~
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: Improve Error Handlers
On Apr 11, 4:26 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > Just a documentation note -- I can't really tell how to use those > features from this page. Are those keyword arguments to urlpatterns? > Functions I call in the pattern list? An example would be helpful. (Replying to myself.) Looking at the code I see they're just urlconf module globals. I assume they only take effect in ROOT_URLCONF? --~--~-~--~~~---~--~~ 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: Improve Error Handlers
On Apr 11, 2:51 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Fri, Apr 11, 2008 at 11:34 AM, David Cramer <[EMAIL PROTECTED]> wrote: > > 404_HANDLER = 'django.generic.views.errors.404' > > 500_HANDLER = 'django.generic.views.errors.500' > > /me jumps in time machine: > > http://www.djangoproject.com/documentation/url_dispatch/#handler404http://www.djangoproject.com/documentation/url_dispatch/#handler500 Just a documentation note -- I can't really tell how to use those features from this page. Are those keyword arguments to urlpatterns? Functions I call in the pattern list? An example would be helpful. --~--~-~--~~~---~--~~ 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: Dictionary lookup with variable in template
On Apr 15, 3:00 pm, tsuraan <[EMAIL PROTECTED]> wrote:
> So {{my_dict | objIndex:Value}} will evaluate Value in the context of
> the current Context, and then pass it to the filter? The HTML
> Template guide says that the argument must be in double quotes, so I
> assume it has to be a literal, rather than a variable that is defined
> in the current Context. Is that wrong?
It should work. As far as I know, filter arguments can be quoted
strings, unquoted integers, or context variables.
--~--~-~--~~~---~--~~
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: django/db/models/base.py - getattr with default?
On Apr 15, 2:53 pm, "ludvig.ericson" <[EMAIL PROTECTED]> wrote: > works better since it doesn't return the data if it exists, or am I > missing something with name lookups? The getattr version handles the case where new_class._meta.app_label does exist, but is None. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] 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 -~--~~~~--~~--~--~---
Aggregates: anything planned for 1.0?
I didn't see anything about aggregate support in VersionOneFeatures[1], are people still hung up about the syntax, or is anyone hacking on this? It's been mentioned a couple times since PyCon, but what's the status? [1] http://code.djangoproject.com/wiki/VersionOneFeatures --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] 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 -~--~~~~--~~--~--~---
Single-argument filters: really a benefit?
I consider this a wart and it's been bugging me for a while. So,
sparked by some discussion in #django, here goes...
I'd like it if template filters supported multiple arguments for real.
Currently filters that need multiple arguments just have to come up
with a delimiter and then do string parsing to get the arguments. This
is not a very good approach and if django.template could recognize
multiple arguments it would relieve filters of this annoying duty.
I'll use this syntax in my examples because it looks like what
django.template already uses for multi-argument tags:
{{ string|filter:"arg1" "arg2" "arg3" }}
...but if that's too much to ask, other delimiters are also
reasonable, ":" and "," look okay.
Here are some arguments for the feature...
- Filters that need multiple *arbitrary* arguments currently aren't
possible. Consider a replace filter: {{ string|replace:"this,with
this" }}. This filter wouldn't be able to deal with strings containing
commas. If commas are expected, the filter author would have to use
some secret crazy string and hope no one uses it. Not Pythonic.
- Mixing literals and template variables in arguments currently
requires string concatenation in the view. Consider the slice filter:
{{ articles|slice:"2:5" }}. What if I want the end index to be passed
as a template variable? Currently I'd have to build a string in my
view ("2:" + str(articles_end)) and pass *that* in as a template
variable, which sucks. {{ articles|slice:"2" articles_end }} would be
much cleaner and have the same semantics as Python's slice built-in.
In one of my projects I really do need to build that silly slice
string because of this limitation.
Current alternatives...
- Tags. Right now if you want multiple arguments you need to use tags.
Is there anything inherent about tags that makes them more
appropriate? I don't think so. The only reason is "because filters can
only take one argument." So people are just going to make tags for
their operations that should be filters, only then they can't be
chained like filters can.
Reasons for the current limitation...
- Syntax. One goal is to keep the syntax as simple as possible. I
don't really think this is an argument since tags take multiple
arguments and filters could use the same syntax for argument passing.
- Separation of logic. People say if the filter logic is that complex,
it should be in the view. I don't think this is an argument either.
How is the string replacement example or the slicing example view
logic? It's still display logic. There's nothing inherently not-
display-logic about a filter that takes two argument vs. a filter that
just allows one. The pluralize and slice filters already prove that
multiple arguments are useful; the built-in limitation is just
unnecessary.
Also consider this: if multiple filter arguments were currently
supported, would there be a compelling reason to remove them? People
would jump ship if that happened...
--~--~-~--~~~---~--~~
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 proposal: django-values
On Apr 9, 9:02 am, "Gulopine" <[EMAIL PROTECTED]> wrote: > > So, my first question is whether this could be designed to work > > without respect to models. For example, there are a lot of cases where > > views might refer to the same data, but not the same models. It would > > seem cleaner if there were a separation (and would avoid complications > > with inner classes vs. overridden fields). In my particular case, it > > would be cleaner to simply have a new class (or classes if it is > > easier to manage) that contains ALL the "constant" data. This does sound useful, and I agree with the above -- the most immediate use cases for my personal projects have little to do with models and more to do with templates. For example, the number of entries to display from my blog feed on my home page. It would be nice to use this project to not have to restart the site just to change that... --~--~-~--~~~---~--~~ 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: Are we dropping auto_now and auto_now_add for 1.0?
Did people feel that save() was a better solution because it's already a place where you have to put equivalent functionality for other fields? I don't know why, but defining my own save() always seems like a "big deal" that should be reserved for more complex stuff. What about a new attribute for all fields, something like: default_condition, where: - The default is set if default_condition(current_value) is True. - By default, default_condition is `lambda value: value is None`, this mimicks current behavior. So: # default_condition is True when created_date is None created_date = models.DateTimeField(default=datetime.now) # default_condition is always True, equivalent to auto_now=True updated_date = models.DateTimeField(default=datetime.now, default_condition=lambda value: True) And it's useful for other fields: minimum_of_zero = models.IntegerField(default=0, default_condition=lambda value: value < 0) --~--~-~--~~~---~--~~ 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: Are we dropping auto_now and auto_now_add for 1.0?
On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote: > It could be just me, but although i don't mind losing auto_*, it don't > look very DRY in save. > > I know it's only a few lines (like 4 ? for both options, not using > default= for sake of keeping the logic together) but when lots of > models > have a cre_date and mod_date, those lines are repeated over and over > again in save(). I agree. Using default= in place of auto_now_add is fine, but writing a save() for every model that needs auto_now is just annoying. A shortcut would be nice. --~--~-~--~~~---~--~~ 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: Django ORM bug when your app has a model named "ContentType"?
Rob Hudson wrote: >> Django has a builtin type called "ContentType", >> http://code.djangoproject.com/browser/django/trunk/django/contrib/con... >> >> I'd just rename yours to something else and be done with it. > > As a workaround, sure. I've already worked around the issue. > > But I don't think Django would want this type of restriction. I've > tried to track how this might get in the SQL myself but it's beyond > me. I'm just offering to help assist or share my model offline if > needed. I agree; if your app isn't using the bundled ContentType, why should Django complain if you make your own? -- Brian Beck Adventurer of the First Order --~--~-~--~~~---~--~~ 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: Autoescaping for 1.0
Brian Beck wrote: > +1 on a noescape "filter" (I'm not too familiar with the template code > but it seems like it would have to be a special case rather than a real > filter). The reason given above sounds right to me: people know when > they don't want something to be escaped. Although, this does make generating non-SGML formats a bit more inconvenient. --~--~-~--~~~---~--~~ 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: Autoescaping for 1.0
Jeremy Bowers wrote: > I've also discovered that even relatively skilled developers can have a > lot of trouble catching every case that needs to be escaped, whereas > almost any developer can correctly determine when *not* to escape > something. The "it didn't work, I'll do X" algorithm that is so popular > is a lot safer when X is "turning off escaping" instead of "turning on > escaping". +1 on a noescape "filter" (I'm not too familiar with the template code but it seems like it would have to be a special case rather than a real filter). The reason given above sounds right to me: people know when they don't want something to be escaped. What about escaping more than just HTML? --~--~-~--~~~---~--~~ 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: Proposal: Named auth backends and backend specific profiles
Jacob Kaplan-Moss wrote: > * The real thing we've been discussing, though, is a way for apps to get ahold > of users after they've been created by a third-party authenticator. For > example, on my sites I'm gonna want everyone to have a username whether they > use OpenID, LDAP, or whatever. > > So after a user has authenticated for the first time (and they're account has > been created), there needs to be a post-account-creation view that they (can) > get redirected to. Something as simple as a POST_USER_CREATION_REDIRECT_URL > setting would be OK, though something more sophisticated would work, too :) I do something similar for my CAS authentication app. Although CAS gives me their username, I call a customizable populate_user function afterwards to populate other fields. It's not a view, but it's a similar idea. I wrote about it here if you're curious: http://blog.case.edu/bmb12/2006/12/cas_for_django_part_2 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
to_field/from_field in ManyToManyFields?
Am I being boneheaded, or should ManyToManyFields support to_field and from_field attributes with the semantics of ForeignKey's to_field? It seems like if ForeignKey supports it then it should be possible in ManyToManyFields as well... --~--~-~--~~~---~--~~ 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: That would be *cookieless* [was: Stateless sessions almost here]
Nicola Larosa (tekNico) wrote: > "Stateless session" is an oxymoron, there's no such thing. You're > talking about *cookieless* sessions. Of course :) I was using them synonymously, i.e. the *browser* has no means of storing state. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Stateless sessions almost here
Hey, So I'm working on a stateless sessions app that people will be able to swap with django.contrib.sessions in their settings if they need that (a recent post mentioned mobile phone browsers for example, apparently they don't support cookies?). I don't actually care that much but I thought it would be a fun hack. Anyway it's almost done, but I need help figuring out one thing. There are two modes supported. In one it adds the session key to the beginning of all your URLs when needed, like so: /session/abcdef123/normal/site/path This is pretty flexible since people are used to mounting sites at non-root URLs, plus you don't have to manipulate query parameter strings which is a pain. The other is to put it in a query parameter like so: /normal/site/path/?session=abcdef123. The app includes all kinds of stuff for making this as easy to deal with as possible. For security it includes a user-overridable request-fingerprint function that forces the request into a new session if it suspects a hijack attempt. Thing I need help with: the query parameters mode *almost* works in the admin interface, but it seems that when browsing models, any extraneous GET parameters trigger the error flag, which makes the page say there's a possible database error. What's up with that? The thing is I can't find the code in the admin app that actually does this check. I see where it renders invalid_setup.html, but not where it's noticing my extra GET parameter... or is something else happening? Any ideas? -- Brian Beck Adventurer of the First Order --~--~-~--~~~---~--~~ 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: New newforms code
Mikko Ohtamaa wrote: Producing HTML is Python is the root of the problem. Most of HTML widget libraries out there use template pieces to produce form output - one template per widget. Have you had any though to move this kind of solution? I already once hacked oldforms a bit to provide me TemplateWidget. Or do you feel this kind of solution would be "core enough" for Django? I just wanted to say that this is the reason I'm reluctant to use Django's forms (new or old) no matter how stable it is. I like that any major chunk of HTML code is visible for tinkering in my template files. Maybe a template solution would be more work (probably some repetition, I haven't really thought about how to combine both some automation and custom template files), but it would also be less surprising for me. -- Brian Beck Adventurer of the First Order --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
UserManager.create_user should accept null email values?
(Tried submitting a ticket, blocked by Akismet.) When creating users with User.objects.create_user, email is a required parameter and fails when None is passed because create_user assumes it will be a string by calling .strip.lower(). However, email is an optional attribute on User. Passing the empty string '' works fine, but I don't think Django should impose the usage of '' for null values on such columns, even if it's recommended. If it wanted to do that, why not have null=False, default='' on the email column? --~--~-~--~~~---~--~~ 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: "getattr(): attribute name must be string"
> The ticket itself is the best guide to any knowledge about the problem; in > this case, I'm guessing that the answer is no - there isn't a patch or > workaround. Any help you can provide in tracking the problem (and/or fixing > it) would be greatfully accepted. Here's a more complete traceback: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py" in get_response 74. response = callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.4/site-packages/django/contrib/admin/views/decorators.py" in _checklogin 55. return view_func(request, *args, **kwargs) File "/usr/lib/python2.4/site-packages/django/views/decorators/cache.py" in _wrapped_view_func 39. response = view_func(request, *args, **kwargs) File "/usr/lib/python2.4/site-packages/django/contrib/admin/views/main.py" in delete_stage 503. _get_deleted_objects(deleted_objects, perms_needed, request.user, obj, opts, 1) File "/usr/lib/python2.4/site-packages/django/contrib/admin/views/main.py" in _get_deleted_objects 464. rel_objs = getattr(obj, rel_opts_name, None) TypeError at /admin/test/person/2/delete/ getattr(): attribute name must be string There seem to be two relevant pieces of code: In _get_deleted_objects: rel_opts_name = related.get_accessor_name() has_related_objs = False rel_objs = getattr(obj, rel_opts_name, None) if rel_objs: has_related_objs = True related.get_accessor_name() can return None, this doesn't account for that. So let's see get_accessor_name, which says: # If this is a symmetrical m2m relation on self, there is no reverse accessor. if getattr(self.field.rel, 'symmetrical', False) and self.model == self.parent_model: return None I tried both commenting out that special case check in get_accessor_name and adding a couple lines to _get_deleted_objects: rel_opts_name = related.get_accessor_name() has_related_objs = False if rel_opts_name: rel_objs = getattr(obj, rel_opts_name, None) else: rel_objs = None if rel_objs: has_related_objs = True This case in particular seems to work fine when either or both of these changes are applied, but I'm not sure if they break something else or are secretly making the database all messy. Anyway, the key point is that anything using get_accessor_name() should take None into account, or None should never be returned. --~--~-~--~~~---~--~~ 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: Idea with respect to full-text indexing
Hi Jeroen, Sorry about the closed blog comments, that entry was getting dozens of spam comments per day even though we use MT-Blacklist. Anyway, your idea seems sound; I'd have to make or see an example implementation and try it out to know if it's the best way to go. Given the current state of search-api, experimentation is definitely the best way towards progress. -- Brian Beck Adventurer of the First Order --~--~-~--~~~---~--~~ 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: Branch Merges?
Gábor Farkas wrote: > - search-api > - i could not find any documentation about it search-api has a wiki page here: http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer There is currently one supported indexer (Lucene) and a couple experimental (Xapian). It needs polish. I blogged about the status a while ago here: http://blog.case.edu/bmb12/2006/08/merquery_summer_of_code_results As for development activity, Rafael Sierra at least has posted some patches, but I won't have time to focus on it more until I graduate in December. If anyone has comments or suggestions about what sucks (besides it being really minimalist right now), I'll be glad to fix it up when I get the chance. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
