proposal for a new ValidationError
What do you think about adding a ValidationError similar to CriticalValidationError but one that would stop further evaluation of _all_ validators in the manipulator instead of just the remaining validators for the current form field being processed? For example, I have a simple login form with username and password that authenticates to an LDAP server. If the user does not have cookies enabled, they fail the hasCookiesEnabled validator on username. However, even if I make hasCookiesEnabled raise a CriticalValidationError, the password validators will still get run and my LDAP server will still get hit. A more desirable outcome would be for me to be able to short circuit processing of all other validators if hasCookiesEnabled fails. A very similar situation can been seen in django.contrib.auth.forms.AuthenticationForm: class AuthenticationForm(forms.Manipulator): def __init__(self, request=None): self.request = request self.fields = [ forms.TextField(field_name="username", length=15, maxlength=30, is_required=True, validator_list=[self.isValidUser, self.hasCookiesEnabled]), forms.PasswordField(field_name="password", length=15, maxlength=30, is_required=True, validator_list=[self.isValidPasswordForUser]), ] Even if username's hasCookiesEnabled validator raised CriticalValidationError, the password's isValidPasswordForUser validator would still get run and hit the database. One issue would be what to name this more-critical-than-CriticalValidationError validation error. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: proposal for a new ValidationError
Bill de hÓra wrote: > Gary Wilson wrote: > > What do you think about adding a ValidationError similar to > > CriticalValidationError but one that would stop further evaluation of > > _all_ validators in the manipulator instead of just the remaining > > validators for the current form field being processed? > > It's not an error, it's a directive to the engine to stop downstream work: > >raise StopValidating Well, it's both. > Personally I don't like it when installed components have the ability to > blow up the containing code /by design/. There's that. There's also > introduction co-concurrence constraints in validators, where validators > depend on other validators being ahead of them to for gigo reasons and > validators are designed to blow up because they 'know' downstream > components are going to be fragile or not doing useful work - imo it > lowers overall robustness. I'd argue the validators teed up this way > aren't cohesive and should be coupled together - either use a strategy > pattern, or nested pipelines*. > > cheers > Bill > > * the validation engine loads one validator, but it's made up of one or > more valdiations which natually belong together and can be locally > optimised. I'm not sure I understand exactly what you mean about blowing up the containing code. The error would be caught in the manipulator's get_validation_errors() method like the other ValidationErrors. I agree with your concurrence statements, order of formfields would become a factor just as ordering of a formfield's validators is important for the CriticalValidationError. hasCookiesEnabled doesn't need to know what's downstream, it wouldn't care. If hasCookiesEnabled validator doesn't pass, the user can't login regardless of what other formfields need validating. You could put the hasCookiesEnabled and isValidPasswordForUser validators together, but I wouln't say that they natually belong together. Maybe the problem is that the hasCookiesEnabled validator isn't really tied to a formfield, but rather is more of a manipulator-level validator. Currently, validators must be coupled to a form field, so that's where the hasCookiesEnabled validator must go. Maybe we could have manipulator-level validators that, if fail, short circuit the evaluating of formfield-level validators. I don't know where the error message would go in the error dict however. Maybe under a "manipulator" key. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
inability to use decorators on template filters
While dealing with http://code.djangoproject.com/ticket/2127, I realized that unless your decorator takes the same number of arguments as the filter function, it will fail since FilterExpression.args_check() (in django/template/__init__.py) is using inspect.getargspec() to count the number of required arguments. Problem is that when using a decorator, getargspec() looks at the decorator's parameters, which usually include *args and **kwargs. The decorator doesn't always have the same number of arguments as the function it's decorating. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Should filters fail silently?
Simon Willison wrote:
> On 10 Jun 2006, at 07:39, Malcolm Tredinnick wrote:
>
> > What's our policy on template filters failing? If applying a filter
> > raises an error, should we just trap it and return the empty
> > string, or
> > raise an error? I can't find this written down anywhere, but maybe
> > I've
> > missed it.
>
> The original policy has always been that errors in template filters
> should fail silently - the idea being that it shouldn't be possible
> to "break" a site by editing a template.
Just to be clear, this following is quoted from
http://www.djangoproject.com/documentation/templates_python/#writing-custom-template-filters
"Filter functions should always return something. They shouldn't raise
exceptions. They should fail silently. In case of error, they should
return either the original input or an empty string -- whichever makes
more sense."
> With hindsight, I think that this was a mistake. An error in a
> template is still an error, and needs to be caught. Failing silently
> just means pages stay broken without the website maintenance team
> hearing about it.
What are the altervatives though? If you raised an error for a
template variable that wasn't defined, you wouldn't be able to do
{{ possibly_undefined }}
or
{% if possibly_undefined %}{{ possibly_undefined }}{% endif %}
Letting undefined variables return empty strings is both flexible and
convenient.
> One particularly nasty example of this is the markdown / textile
> filters. At the moment, these will fail silently if the markdown or
> textile modules aren't installed - they will just output the string
> that was piped to them. Imagine you have markdown/textile installed
> on your development machine but not on your production machine. You
> upload your site but forget to test the pages in question - as a
> result, visitors to the site see unformatted markdown instead of HTML.
>
> In this case, throwing and logging an error is much preferable to
> failing silently.
Maybe in the case of the markdown / textile filters failing, it would
make sense to return an empty string rather than the text that was feed
to them.
Logging (or mailing admins) wouldn't be a bad idea either, but in the
case of http://code.djangoproject.com/ticket/2127, you don't need to
log that the filter failed. It should just act the same as if there
was no filter and return an empty string if the variable 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 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
-~--~~~~--~~--~--~---
Re: Should filters fail silently?
FYI, here is a previous django-dev discussion Failing silently, and documentation thereof http://groups.google.com/group/django-developers/browse_thread/thread/40adac6370fc195c/b1656b8e0c036c04 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: default escaping
gabor wrote: > is it true, that people usually forget to escape dangerous variables? > > > a) if no (people do not forget): > means people are already using 'escape' when needed. in this case, this > block-level tag is a welcome addition, because it makes it > simpler/more-convenient to toggle escaping. > > > b) if yes (people do forget): > a block level tag will not help. people will forget to use them the same > way they forget to use the 'escape' filter. > > my guess is (b) or c) people don't know what XSS is and are clueless about the need to escape. A good case for turning escaping on by default. What would you rather have: "Help, help! How do I turn off escaping?" or "Help, help! H4a0r s+0l3|> my Dj4|\|g0111" --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: #2217 - Filtering using objects rather than IDs
Russell Keith-Magee wrote: > I've just committed r3246 which implements the change. Thanks Russell. This is certainly more natural. This really should be added to the model api documentation too. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: #2217 - Filtering using objects rather than IDs
Gary Wilson wrote: > This really should be added to the model api documentation too. db api rather. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
would is_loggedin be better than is_anonymous?
Proposing an is_loggedin method for User and AnonymousUser models. Templates treat non-existing variables as False; therefore; a request.user somehow failing to get assigned would result in the template treating the user as they are authenticated (is_anonymous evaluates False). An is_loggedin would be a more secure option because if request.user failed to get assigned, the template would treat the user as anonymous. I would much rather mistakenly treat an authenticated user as anonymous than mistakenly treat an anonymous user as authenticated. is_anonymous could be changed to return the negation of is_loggedin. 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 -~--~~~~--~~--~--~---
Re: Templates and user.is_anonymous
déjà vu http://groups.google.com/group/django-developers/browse_thread/thread/2cc178fe7c8c9046/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: would is_loggedin be better than is_anonymous?
Thinking of this some more, I'm wondering about the names is_logged_in or is_authenticated. They could be a little misleading since they aren't really checking if the user is logged in or not. One might be led to believe that they could do something like logged_in_users = [user.is_logged_in() for user in User.objects.all()] or something like user = User.objects.get(username='fred'); if user.is_logged_in(): ... It seems that maybe the is_anonymous function is just a way for the object to say it's either an AnonymousUser object or it's not an AnonymousUser object. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
related object's fields in the admin options
So I've got a model resembling:
==
from django.contrib.auth.models import User
class ExtendedUser(models.Model):
user = models.OneToOneField(User)
class Admin:
list_display = ('user',)
search_fields = ('user',)
==
The admin has a user column but it is sorted by User.id and therefore
not sorted alphabetically. Nor can you search on the string that
User.__str__ returns. This makes things very difficult. I think it
would be nice if the related object's fields were allowed for
list_display, search_fields, etc. This would be allowed for
OneToOneFields and ForeignKeys.
For example I would like to be able to do something like the following:
class Admin:
list_display = ('user.last_name',)
search_fields = ('user.last_name',)
or
class Admin:
list_display = ('user__last_name',)
search_fields = ('user__last_name',)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: related object's fields in the admin options
Jay Parlar wrote:
> You can use functions inside list_display:
>
> class Admin:
> list_display = ('get_last_name',)
>
> def get_last_name(self):
> return self.user.last_name
> get_last_name.short_description = "Last Name"
But you can't sort or seach it.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: would is_loggedin be better than is_anonymous?
What if we instead make it so that context_processor.auth only sets the
"user" template variable if request.user is not an AnonymousUser
instance and then in templates you would use
{% if user %}
I am logged in.
{% endif %}
to determine if the user is logged in. If the user is not logged in,
then the "user" template variable will not get set and then the above
would evaluate to False.
I also got to thinking about the AuthenticationMiddleware setting
request.user to None instead of an AnonymousUser object (and doing away
with the AnonymousUser class) when the user is not logged in; however,
in views and code it is probably nice to be able to things like
request.user.has_perm('myperm') without having to put an "if user:"
check before it all the time.
But in the templates, this is not the case because you can do {% if
user.has_perm('myperm') %} without doing an {% if user %} check since
the "user" template variable wouldn't exist and would evaluate to False.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: related object's fields in the admin options
Luke Plant wrote:
> On Wednesday 12 July 2006 21:27, Gary Wilson wrote:
> > Jay Parlar wrote:
> > > You can use functions inside list_display:
> > >
> > > class Admin:
> > > list_display = ('get_last_name',)
> > >
> > > def get_last_name(self):
> > > return self.user.last_name
> > > get_last_name.short_description = "Last Name"
> >
> > But you can't sort or seach it.
>
> Because that is impossible to do in SQL. Consider the case, for
> example, where you've got 1,000,000 rows, and need to get display page
> 20, containing items 2000 - 2100 in the admin. You can only do that
> efficiently if you do it in SQL
Wouldn't the SQL just be a join and an order by with a limit/offset?
> You could, however, write an SQL view which provided the columns you
> wanted to search/sort on, and use that instead of your table. To
> update records your DB will have to support updateable views (or
> perhaps you could do some hacks in .save())
The admin interface wouldn't be updating records, but rather just
displaying data from the object's own fields as well as from it's
related object's/objects' fields.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: related object's fields in the admin options
Luke Plant wrote:
> In that particular case, yes (and in this instance it might be possible
> to implement what you want be writing a custom manager and overriding
> get_query_set() so that it adds a join and custom ordering), but there
> is no (feasible) way of introspecting get_last_name() and working this
> out, since Python functions can contain any Python code.
Please look at my original post, I am not trying to use a
get_last_name() method.
What I am proposing is to have the query strings in the admin options
act like query strings when you are a performing a query with the
database api (namely, to be able to use the related objects' fields).
Example:
We can already do things like:
ExtendedUser.objects.filter('user__last_name__icontains'='Wilson')
where we are searching the last_name of the related User object.
but I am thinking we should also be able to do the same with order_by:
ExtendedUser.objects.all().order_by('user__last_name')
which, in turn, could allow things like
list_display=['user__last_name', 'user__first_name']
ordering=['user__last_name']
in the admin options of a model.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: would is_loggedin be better than is_anonymous?
SmileyChris wrote:
> I think we still need the AnonymousUser and from the number of
> references to is_anonymous in python modules I think we still need a
> negation of it.
Yes I think AnonymousUser is still helpful in python code, and yes I
think we should deprecate is_anonymous before removing it.
> So how can we work towards a consensus on the best name for a function
> which is the negative of is_anonymous?
I think I now vote for is_authenticated since the is_loggedin versions
could more easily be taken the wrong way (by trying to lookup all users
who are logged in). I would be less inclined to try and lookup all
users who are authenticated. Make any sense?
> On a side note, in templates I don't think you can actually do {% if
> user.has_perm('myperm') %} anyway.
Yes, I must have been brain dead. But it would still hold true that
the "user" template variable could just not be set instead of setting
it to an AnonymousUser instance. Hmm, this would break pretty badly
for people using {% if not user.is_anonymous %} in their templates
though since it would then treat all non-authenticated users as
authenticated. So scratch this idea.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Do we need an escaped version of unordered_list?
Malcolm Tredinnick wrote:
> Is there any alternative to creating an escaped_unordered_list tag? (Any
> better name for this tag? It's too long)
How about {{ obj_bag|unordered_list:"escape" }} ?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: related object's fields in the admin options
I think I will first attempt to allow order_by to accept related
objects, like order_by('user__last_name'). Could someone please point
me in the right direction? I am not too familiar with django's db
code. What all would need changing?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: would is_loggedin be better than is_anonymous?
And so are we keeping is_anonymous or deprecating it? I guess it would still be useful for determining whether on not your object is an AnonymousUser instance, which seems to be it's original intent. We can keep it and just change the docs to use is_authenticated. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Akismet spam filtering for Trac
Has anyone seen/tried the Akismet spam filtering plugin for Trac: http://trac.edgewall.org/wiki/SpamFilter#Akismet Would be nice for Django's trac. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Akismet spam filtering for Trac
> """ > 2006-07-17 17:13:08,419 Trac[__init__] WARNING: 500 Internal Error > (Akismet rejected spam) > """ > > Seems to be working. Good to hear. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: would is_loggedin be better than is_anonymous?
Patch for is_authenticated implementation with doc changes and no deprecation warnings in is_anonymous. Please review. http://code.djangoproject.com/attachment/ticket/2332/is_authenticated.2.diff --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Strip Whitespace Middleware
I never really liked how the templating system leaves all those newlines. This middleware is cool, but it would really be nice if the templating system could collapse the lines that only contain one or more evaluating-to-nothing template tags. Thoughts on a possible implementation: What if an endofline token were added. Lexer.tokenize() creates the tokens and Parser.parse() creates the nodelist like normal. Each node in the nodelist is rendered, except for endofline nodes. Pass through nodelist again, removing whitespace-strings and empty-strings if those whitespace-strings and empty-strings are all that exist between two endofline nodes. The endofline nodes following removed whitespace-strings or empty-strings are also removed, while all other endifline nodes get rendered to a newline. Join and return rendered nodelist like normal. Would this work? Is there a better way? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
the template system's whitespace handling
Malcolm Tredinnick wrote:
> On Tue, 2006-08-01 at 22:53 -0700, Gary Wilson wrote:
> > I never really liked how the templating system leaves all those
> > newlines. This middleware is cool, but it would really be nice if the
> > templating system could collapse the lines that only contain one or
> > more evaluating-to-nothing template tags.
> >
> > Thoughts on a possible implementation:
> >
> > What if an endofline token were added. Lexer.tokenize() creates the
> > tokens and Parser.parse() creates the nodelist like normal. Each node
> > in the nodelist is rendered, except for endofline nodes. Pass through
> > nodelist again, removing whitespace-strings and empty-strings if those
> > whitespace-strings and empty-strings are all that exist between two
> > endofline nodes. The endofline nodes following removed
> > whitespace-strings or empty-strings are also removed, while all other
> > endifline nodes get rendered to a newline. Join and return rendered
> > nodelist like normal.
> >
> > Would this work? Is there a better way?
>
> The big question with this sort of thing is always going to be speed.
> Rendering templates is pretty fast at the moment, but it wants to be,
> too. That being said, I haven't implemented or profiled your approach,
> so I have no idea of its real impact, but you are introducing another
> pass over the source text chunks (chunks == the results of an re.split()
> call).
>
> I've been experimenting with a somewhat funky reg-exp change inside the
> template parser that would have the same effect as yours. I'm still
> optimising it (I *knew* there was a reason that part of Friedl's book
> existed) and profiling the results, but it looks possible. Essentially,
> this would have the same effect you are after: a blank line that results
> from just template directives is removed entirely. Any spaces or other
> stuff on the line are left alone, though, so it's a very selective
> reaper.
>
> My motivation here was having to debug an email generation template
> yesterday that was like a train wreck with all the template tags jammed
> together to avoid spurious blank lines. It's going to be a few more days
> before I can work on this seriously, I suspect (there are two more
> urgent Django things I need to finish first, for a start), so you might
> like to experiment along those lines too, if you're keen. I'm not sure I
> like my solution a lot, either, since it makes things a little more
> opaque in the code; still having debates with myself about that.
>
> Regards,
> Malcolm
Breaking this discussion off from Strip Whitespace Middleware.
So, I think that the template system should not leave blank lines
behind if the tag(s) on that line evaulated to the empty string. To
make sure we are all on the same page, here is an example:
This template code:
My list
{% for item in items %}
{{ item }}
{% endfor %}
Would normally evaluate to:
My list
item 1
item 2
item 3
And with the {% spaceless %} tag evaluates to:
My list item 1 item 2 item 3
And with the StripWhitespace Middleware evaluates to
My list
item 1
item 2
item 3
====
But what I think should evaluate to:
My list
item 1
item 2
item 3
In other words, leave lines that I add, but remove the empty lines that
had template tags on them.
Gary Wilson
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: 'filesize' patch for humanize
Just thought I might share a size converter I wrote a while back... def bytesToHumanReadable(bytes, binary=True, precision=1): """Convert bytes to a human-readable size. Given a size in bytes, this function converts it and uses the largest suffix possible that does not result in a size that is less than 1 (i.e. 300 KiB instead of 0.3 MiB). By default use binary size-prefixes, and if binary=False then use SI size-prefixes. """ if binary: factor = 1024 suffixes = [ 'B',# bytes 'KiB', # kibibytes 'MiB', # mebibytes 'GiB', # gibibytes 'TiB', # tebibytes 'PiB', # pebibytes 'EiB', # exbibytes 'ZiB', # zebibytes 'YiB', # yobibytes ] else: factor = 1000 suffixes = [ 'B',# bytes 'KB', # kilobytes 'MB', # megabytes 'GB', # gigabytes 'TB', # terabytes 'PB', # petabytes 'EB', # exabytes 'ZB', # zettabytes 'YB', # yottabytes ] format = '%.*f %s' # Change to float so we don't lose precision in the division operation. size = float(bytes) for suffix in suffixes: if size >= factor: size /= factor else: if suffix is suffixes[0]: # Do not use precision for size in bytes. precision = 0 return format % (precision, size, suffix) # We are at the end of the suffix list, anything this big gets put into # units of the last suffix in the list. return format % (precision, size, suffixes[-1]) Some examples: >>> bytesToHumanReadable(1023) '1023 B' >>> bytesToHumanReadable(1024) '1.0 KiB' >>> bytesToHumanReadable(3215436) '3.1 MiB' >>> bytesToHumanReadable(998436) '975.0 KiB' >>> bytesToHumanReadable(163456887454) '152.2 GiB' >>> bytesToHumanReadable(163456887454, binary=False) '163.5 GB' >>> bytesToHumanReadable(163456887454, binary=False, precision=8) '163.45688745 GB' >>> bytesToHumanReadable(16345688745446468445546546) '13.5 YiB' --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: the template system's whitespace handling
Malcolm Tredinnick wrote: > That was where I was coming from, too. Oh yeah, I meant to ask you more about the implementation you have. Is it functional? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: modularity of apps
Malcolm Tredinnick wrote: > > Or maybe we don't need any of this and I'm just being overly anal > > retentive. > > Not at all. Particularly as people start trying to write more Django > applications that are designed to be sharable beyond their immediate > development group, we are going to see more and more of this. First off, I think it would be good for applications to have their own settings file. Currently, if I want to install another django application I have to add it to INSTALLED_APPS, make sure it has the TEMPLATE_CONTEXT_PROCESSORS it needs, the MIDDLEWARE_CLASSES it needs, the AUTHENTICATION_BACKENDS it needs, the cronjobs it needs, and edit the project's urls.py. And in the future, we might also have escaping settings (when auto-escaping lands), database settings (when multi db support lands), and so on. The reason why these need to be specified per app is because TEMPLATE_CONTEXT_PROCESSORS can clash, MIDDLEWARE_CLASSES can clash, etc. I recently ran into a problem where the above clashes happened. I have an app that uses it's own user table. Well, the multi auth login function sets the cookie session data to the id of the authenticated user. But the id is an id for my app's user table, and if I were to authenticate to my app and then go to django admin app, things break. Things also break if I want a context processor to use the template variable 'user' since django.core.context_processors.auth also uses the 'user' variable. Same goes for twe middleware classes both setting request.user. Yes, I could use different template variable and class attribute names, but now extra work is being done because my apps context processors are running as well as the admin's context processors. The more apps you have, the worse things get. Maybe an application should be able to specify whether the middleware class it uses should be applied globaly throughout the project or applied only to urls handled by that app? Would that be too complex? Or maybe the solution is to keep your django projects small and only use a couple applications per project. Then you essentially have "per app" settings. Per app settings I think would go a long way in making applications more "packaged" though. Maybe settings not specified in the app would carry over from the project's settings? So if I want to use the same database then I wouldn't specify one in my app's settings. Then there is the issue, which I think was mentioned earlier, about how do you insert the app's middleware classes into the project's middleware classes since order does matter. Or maybe instead you specify all the middleware classes to be used in the app and don't do any inserting into the project's middleware classes. Sorry if the above isn't very coherent. It's late and I was just trying to throw some ideas out there. I also have some beef with the template directories and loading, but I will save that for another email. Gary Wilson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: flat values() in querysets
Adrian Holovaty wrote:
> Oooh, that's a nice idea. I'm not 100% certain "flat=True" is the best
> name for it, but I can't think of anything better at the moment. Would
> you be willing to submit a patch?
Maybe .flatvalues("id", "name") or .valuelist("id", "name") ?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: #2406: [patch] new command for management -- runjobs
Michael Radziej wrote: > Adrian Holovaty wrote: > > If your goal is to cut crontab entries from five to one, just create a > > single script that does the five things you need it to do; then point > > crontab at it. :) > > But it would be fine for pluggable applications to make this > automatically! (I'm +1) > > Michael +1 for periodic job running abilities Yes, let's move towards more modular applications, please. Session clean up should be, gasp, in the session application. Django should be making my server admin life easier, not harder. Gary Wilson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and LDAP support
Scott Paul Robertson wrote: > On Tue, Aug 01, 2006 at 12:08:25PM -0700, Scott Paul Robertson wrote: > > I'm actually doing LDAP auth with something I wrote myself, which I feel > > is a little more general than the mentioned code (not that I'm > > opinionated or anything). I'll be posting it in a day or so once it's > > cleaned up a bit more. During OSCON I mentioned to Adrian that I'd be > > willing to work on one that would make it into django. > > > > I've finished the code for a backend that works with LDAP. It pulls all > the needed variables from your settings.py file, and covers everything > that I could think of. I don't have an ssl based ldap server to test > with, but I think if you want ssl you only have to have the uri be > ldaps:// instead of ldap://. I believe ssl with RedHat EL works out of the box since in sets TLS_CACERTDIR /etc/openldap/cacerts in /etc/openldap/ldap.conf. My gentoo box needed the ca-certificates package and I set this up in my python code using ldap.set_option(ldap.OPT_X_TLS_CACERTDIR, '/usr/share/ca-certificates') but I think you could alternatively set TLS_CACERTDIR in /etc/openldap/ldap.conf. > Scathing comments are encouraged. line 68 of patch: if not username and password is not Null: # we need a user/pass Should be None And how about moving the ldap.initialize() call after the above check so that we don't make an unneeded connection to the ldap server. Also, in the ldap setup I deal with, you must bind to the server using a service account before attempting a bind with the user-supplied credentials. The process goes something like 1. Retrieve the username and password from the user. 2. Bind to the directory using DN and password of service account. 3. Issue a search query to determine the user's DN based on their username. 4. Attempt to bind to the directory using the user's DN retrieved in step 3 and the password supplied by the user in step 1.. 5. A successful bind means that the user has been authenticated. An unsuccessful bind means that the credentials provided are invalid. This also seems to be the method used/needed in the second resource link you listed in your first post. It would be great if this method could be supported. It would require a few more options like LDAP_SERVICE_BIND_DN LDAP_SERVICE_BIND_PASSWORD and then an additional check in authenticate() (after the call to initialize() and before the bind with the user's DN and password) to see if first a bind should be attempted with the service account DN and password. Gary Wilson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and LDAP support
Scott Paul Robertson wrote: > > Also, in the ldap setup I deal with, you must bind to the server using > > a service account before attempting a bind with the user-supplied > > credentials. The process goes something like > > > > 1. Retrieve the username and password from the user. > > 2. Bind to the directory using DN and password of service account. > > 3. Issue a search query to determine the user's DN based on their > > username. > > 4. Attempt to bind to the directory using the user's DN retrieved in > > step 3 and the password supplied by the user in step 1.. > > 5. A successful bind means that the user has been authenticated. An > > unsuccessful bind means that the credentials provided are invalid. > > > > This also seems to be the method used/needed in the second resource > > link you listed in your first post. It would be great if this method > > could be supported. It would require a few more options like > > LDAP_SERVICE_BIND_DN > > LDAP_SERVICE_BIND_PASSWORD > > and then an additional check in authenticate() (after the call to > > initialize() and before the bind with the user's DN and password) to > > see if first a bind should be attempted with the service account DN and > > password. > > > > I'll start on this tomorrow. Out of curiosity how common is this sort of > setup? I've only seen a handful of LDAP implementations, and this is new > to me. Not sure how common it is, as this is the only ldap setup I have worked with. The directory has controlled access via issued service accounts, in addition to user accounts. The service accounts allow applications to access the directory without having to use a regular user's credentials. I believe this gives the system better access control and logging. Gary Wilson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
multiple authentication and session keys
So, the mutli authentication seems to work well for the use case of a site accepting more than one authentication source to access some area, but not so well for the use case of a site accepting one source of authentication in one area and another source of authentication in a different area. The contrib.auth.login function currently writes the user's id to session['_auth_user_id'] and the backend to session['_auth_user_backend']. When using more than one authentication backend, the session data gets stomped on. I propose that the session data be keyed by backend somehow so that authentication session data is kept separate. The login function would change to key the session data by backend. The logout function would log the user out of all backends, or optionally take in a backend to log the user out of only that particular backend. The get_user function with no parameters would return the first user object it finds calling backend.get_user() for each backend in AUTHENTICATION_BACKENDS in order, or optionally take a backend to try and get the user from. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and LDAP support
Scott Paul Robertson wrote: > Let me know if there's anything else, > Scott You can remove the l.unbind_s() on line 77. It would also be great if the authenticate() method wasn't tied to the contrib.auth.models.User model. I, for one, use my own custom user model. Maybe extracting the parts that try to get and update the user in authenticate() could be extracted to another method so that people using a custom user model could easily override these methods. Maybe the LDAP_BIND_STRING_FUNC should be moved to a class method instead, which would be empty by default? Then you could just inherit LDAPBackend and override this pre_bind() method if you wanted to do something special (like bind with a service account first). This pre_bind() could be called after intialize() and be passed the ldap object and username, just as LDAP_BIND_STRING_FUNC. I have yet to test the patch, but I hope to try it out later this week at work. Gary Wilson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: modularity of apps
Malcolm Tredinnick wrote: > One point of view (mine!) is that if an application can't play nicely > with other applications and wants to do its own authentication, etc, > then it's not an application, it's a whole other project. The project > developer should have complete control over what the policies are for > things like this. Otherwise it's too hard to understand what each app is > doing when incorporating it. So if am using the admin application with its (contrib.auth) authentication and then the rest of my site using a custom user model with its own authentication, you are saying that I should make them separate projects? That just doesn't seem right. I don't think anyone has answered the OP's question of how plugable are apps supposed to be? Currently, the only way you can achieve full modularity is to make every installed app its own project. Only then can I set the app's TEMPLATE_CONTEXT_PROCESSORS, MIDDLEWARE_CLASSES, AUTHENTICATION_BACKENDS, etc. and be sure that applications won't stomp over each other. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: the template system's whitespace handling
Tim Keating wrote: > I agree. It seems to me people either care about this or they don't. > Ergo the Django way to do this would be to make the whitespace handler > pluggable and set it globally in settings.py. If performance does not suffer, I'm with Malcolm that it should simply be done by default with no extra settings. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: modularity of apps
James Bennett wrote: > On 8/13/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > The Lawrence guys have mentioned on this list previously that they have > > many different applications they pull together in various projects. > > :) > > If we couldn't modularize, we wouldn't be able to sell different > "editions" of Ellington. Maybe they could enlighten us on how they modularize. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: modularity of apps
James Bennett wrote:
> The more I think about it, the more I like the idea of using imports
> in __init__.py to specify an application's dependencies; the thing
> that'd make it especially nice would be some method -- either
> conventional or built straight in to Django -- of checking for
> "importable" versus "installed" and for throwing nicer error messages.
> Something like this, maybe:
>
> from django.conf import settings
>
> dependencies = (
> {'name': 'tags', 'module': 'foo.tags'},
> {'name': 'todo', 'module': 'bar.todo'},
> {'name': 'comments', 'module': 'django.contrib.comments'},
> )
IMO, the dependency checking is the easy part. In the README or
something, I say MyCoolApp requires the admin app. It's the
configuration settings of the admin app that's hairy.
So let's say MyCoolApp needs the admin app to function. (Let's ignore
the fact that, by default, Django adds everything to settings.py that
the admin app needs to run even though I don't need most of them if I'm
not using the admin app.) So, in MyCoolApp.__init__.py I put the
following:
dependencies = (
{'name': 'admin', 'module': 'django.contrib.admin'},
)
What has this bought me?
Not much considering I still need to make sure I have
ADMIN_MEDIA_PREFIX set, SECRET_KEY set,
'django.template.loaders.app_directories.load_template_source' in my
TEMPLATE_LOADERS,
"django.contrib.sessions.middleware.SessionMiddleware" and
"django.contrib.auth.middleware.AuthenticationMiddleware" and
"django.middleware.doc.XViewMiddleware" in my MIDDLEWARE_CLASSES,
'django.core.context_processors.auth' and
'django.core.context_processors.i18n' and
'django.core.context_processors.request' in my
TEMPLATE_CONTEXT_PROCESSORS,
'django.contrib.auth.backends.ModelBackend' in my
AUTHENTICATION_BACKENDS, "django.contrib.admin" in my INSTALLED_APPS,
and (r'^admin/', include('django.contrib.admin.urls')) in my urls.py.
Somebody help me if I ever wanted to bring down an application for
maintenance. Just removing it from INSTALLED_APPS ain't going to do
it. You can check the importing of an app or it's presence in
INSTALLED_APPS, but that app could still be a good ways from being
"installed."
> Anything more complex would be tending a bit too much toward the "app
> server", I think.
What do you mean a bit too much toward the app server? Isn't that what
we are all doing with django? Building and serving blog apps and forum
apps and news publishing apps and ...
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Abstract classes support in models
James Bennett wrote: > The new and improved model inheritance that Malcolm is working on will > also provide a facility for abstract "base" classes, so I'm thinking > this would probably be redundant; there's also been discussion on this > list of how the syntax should work, and IIRC the consensus was for a > new base class, so that for your abstract class you'd do Is this still waiting on django.db.models refactoring? The wiki page hasn't been updated in a while. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: modularity of apps
James Bennett wrote:
> On 8/17/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> > IMO, the dependency checking is the easy part. In the README or
> > something, I say MyCoolApp requires the admin app. It's the
> > configuration settings of the admin app that's hairy.
>
> That's what application documentation is for. In theory it's also
> possible to use this mechanism to ensure that any additional settings
> it requires exist in the project settings file and are non-empty;
> something like
>
> from django.conf import settings
>
> try:
> my_cool_app_setting = settings.COOL_APP_SETTING
> except AttributeError:
> dependency_errors.append("the setting 'COOL_APP_SETTING' must be
> specified in the project's settings file in order to use this
> application")
>
> But as Malcolm has pointed out, the idea here is not to provide a
> mechanism for automatically configuring applications -- it's to
> provide a way for applications to specify the things they need.
Yes I think that, at the least, a mechanism for checking that apps have
everything they need would be great. I was more trying to point out
that simply checking INSTALLED_APPS is not sufficient. It would be a
good start though.
I am more concerned about when Djangoers start sharing apps more. (For
instance, a Django application repository has been brought up a couple
times on the list. Continuing to add applications to contrib is not
going to scale.) I wouldn't want a context processor of an application
I grabbed from some shared repository to be able to interfere with a
context processor of an app I already have installed. Or if it did
interfere, then it would be nice if this could be caught by some sort
of validation check.
I also think that the check should be only a warning. The admin app
has checks in its code that makes sure that
django.core.context_processors.auth is in TEMPLATE_CONTEXT_PROCESSORS,
but I had another application where I wanted to set a context variable
with the same name. To do this you have to remove the
django.core.context_processors.auth. But then you can't use the admin
app because it will raise an error, even if I have a custom context
processor that runs either my application's context processor or the
auth context processor depending on which application was "handling"
the request. Applications shouldn't be able to so easily polute the
context variable namespace for every installed application.
The default template loaders suffer from this same type of polution.
Let's say I want the admin app installed, which in the template
directory namespace uses admin, admin_doc, registration, and widget.
Now if I later made a registration app (or any application that wanted
to use a folder named registration to hold its templates), I would be
in trouble. One application shouldn't go looking in all the template
directories of every other installed application. That's just wrong.
Many users want to extend or alter the admin or authentication
applications, but can't because they are so intertwined with each other
(and other Django core) that it makes things hard to change. By making
applications more modular, you also make them more extensible.
> > What do you mean a bit too much toward the app server? Isn't that what
> > we are all doing with django? Building and serving blog apps and forum
> > apps and news publishing apps and ...
>
> In my mind, at least, an "app server" is a system whose job is to take
> many different applications which may be written using wildly
> different frameworks, or even no frameworks at all, and mediate
> between them (assuming, for example, that they implement some common
> interface for communication with the app server). WSGI is a good
> example of this sort of thinking in the Python world -- the idea is
> that it doesn't matter what you use to write your application, so long
> as it exposes the appropriate WSGI-compliant interfaces for its
> intended role.
>
> That seems to be far and away a larger and more complex task than what
> Django aims for -- yes, Django provides facilities for Django-based
> applications to work with one another, but Django is first and
> foremost a tool for _writing_ applications, not a tool for _running_
> applications.
I would never expect Django to handle apps written in other frameworks,
but surely Django should be able to run it's own apps well. I would
argue that Django is just as much a tool for running Django
applications as it is a tool for writing Django applications. What
good is writing a Django application if I don't have some equally good
way to run it?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
limodou wrote: > There are some threads talking about the apps repository already, but > till now, no repository be found. So I want to suggest again: we > should build an official project web site to host django apps or > projects. So we can easy share our source code and exchange our ideas. > And I think 0.95 is stable enought, and why we still need to wait 1.0, > if there is an official web site to host these things, we can reuse > others source code easily and make django more improvement I think. I think this is a great idea. Anyone have suggestions on to how this should be organized? One big repository or several small ones? Everybody with an account has access to all projects or form teams for each project? Should every project have its own Trac instance? Separating the projects and forming teams would be more of a Django mini-SourceForge, and while this might be ideal, it would require quite a bit more work to setup. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: the template system's whitespace handling
I created a ticket:
http://code.djangoproject.com/ticket/2594
I also attached a patch that I have done a little testing with and
seems to work ok. I first attacked this at the Node level, but
realized that might not be the best way because the Nodes get rendered
recursively. In order to clean up the line's whitespace, you would
have to wait for everything to render and then remember which
lines/templatetags/templatevariables the render originated from.
The patch attacks the problem at the token level. It finds the end of
lines and then evaluates each line to determine if whitespace should be
cleaned up. But the patch is not perfect. If you have lines in your
template like:
{% for item in items %}{{ item.name }}{% endfor %}
or
{% if item.name %}{{ item.name }}{% endif %}
where blocks are on the same line as text and the block renders no
output, my patch is fooled and still will insert a blank line in the
rendered string.
If, however, you were to instead write the above examples as:
{% for item in fooitems %}
{{ item.name }}
{% endfor %}
or
{% if item.name %}
{{ item.name }}
{% endif %}
then my patch will clean up the whitespace nicely. This patch may also
very well not work on windows due to the different line endings.
There are a few setbacks though. It seems that with this patch,
render_to_string becomes 2-3 times slower. Toying with python's
profile for a few minutes shows that most of the time was being spent
in Token.__init__ and Node.__init__, which seemed logical due to all
the extra tokens, and hence nodes, that get created when using my 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
-~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
limodou wrote: > I think if this functionality built on django official site is the > better, because every djangor can easy find it. I think the first > stage could be the index site supplied by django site, and the exact > projects could be found everywhere. And the second stage could be > hosting the most django relative projects in django repository site. As for a first stage, the djangoproject wiki would work. For example, a contributed middleware page already exists: http://code.djangoproject.com/wiki/ContributedMiddleware --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
Ian Holsman wrote: > luckily? for me I have a bit of time on my hands tomorrow and > possibly monday. > i could get a start on something 'forgish' which could then be used > to critique/improve on. Ian, does this mean you are working on a DjangoForge written in Django? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Thoughts on extensibility of the admin app
One of the cool things about the admin app is the form building, something that I wish were easier. Stuff like the AdminBoundField would be nice to have outside of the admin (I don't know, is this already easy to do?). I am assuming that the admin app will be rewritten with the arrival of the new form system that is in the works, and that the new form system should make admin-like forms more re-usable. Is that 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 -~--~~~~--~~--~--~---
Re: multiple authentication and session keys
So I hit another little snag today related to this. The contrib.auth.middleware.LazyUser calls contrib.auth.get_user (knowing where to get the user from based on the backend stored in session['_auth_user_backend']), which will return an authentication-backend-dependent user object. This user object shouldn't have to conform to contrib.auth.models.User's interface, yet core.context_processors.auth calls request.user.get_and_delete_messages(). This means that whatever user object I return with my backend must implement a get_and_delete_messages method. Another problem with the request.user.get_and_delete_messages() call is that request.user is a LazyUser. So LazyUser is doing us no good since this call will always put LazyUser to work. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
Jeremy Dunck wrote:
> On 8/31/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > I mean when you're creating a manipulator you can list fields that you
> > don't want it to touch:
> >
> > manipulator = Owner.AddManipulator(follow={'thing': False})
>
> Thanks; I don't see that documented. Probably because manipulators
> will go away...
I'm not sure if it's up to date, but there is mention of the follow
here:
http://code.djangoproject.com/wiki/NewAdminChanges#Manipulatorsandinlineediting
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: multiple authentication and session keys
Adrian Holovaty wrote: > Thanks for bringing this up, Gary. The get_and_delete_messages() thing > has always bothered me -- if it's activated, we do it for every > request. I suppose we could make the 'messages' part of the context > processor lazy, so that it would only call get_and_delete_messages() > if that variable were accessed in the template... Thoughts? We could make the messages part lazy, but we also don't want to have to pass it request.user because that defeats the purpose of LazyUser. What if we gave the LazyUser class a lazy "messages" property and dont pass a "messages" context variable in the context processor. The templates would instead access messages through the "user" context variable. Of course, this would make the templates backwards incompatible. As far as Django code, the messages variable seems to get used only in contrib/admin/templates/admin/base.html. I think it would be a good idea to add some re-usable Lazy object class to Django, something like this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/363602 This lazy loading stuff is a common scenario. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
Jacob Kaplan-Moss wrote: > On Aug 25, 2006, at 7:04 AM, DavidA wrote: > > One comment on ValidationErrors: When I've done these types of things > > in the past, I've typically returned two levels of validations > > messages: warnings and errors. An error indicates that the attempted > > save will fail (i.e. it would either cause a an object to be saved in > > an invalid state or it would violate a DB constraint and throw an > > exception in the backend). A warning would not result in a failure but > > is still worthy of notifying the user, but there are cases where > > its OK > > so its not identified as an error. > > Yes! This is something that I forgot about -- we've wanted to add > validation warnings to Django as long as I can remember. > > > So I'd suggest a ValidationException that has an errors dict, a > > warnings dict and possibly a form (or a very easy way to create a form > > from the exception). I would also love to see a way to throw a validation error at the form/manipulator level that would short circuit further validation at the field level. For example, I have a login form and want to attach a hasCookiesEnabled validator at the manipulator level so that if the user didn't have cookies enabled, further validation would be skipped (saving hits to my authentication server and database server) and a manipulator level error would be raised. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
do timesince and timeuntil template filters really need millisecond resolution?
Just seems a bit silly to me. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
yes/no option for BooleanField
After noticing the new NullBooleanField, I am thinking it would be nice to have the same sort of yes/no dropdown option for BooleanField (without the "unknown" choice of course). What do you think? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: yes/no option for BooleanField
Adrian Holovaty wrote: > I'm -0 on having BooleanFields use a drop down in the admin interface. > Radio buttons are so much more usable, if you only have two choices. > If anything, we should change NullBooleanFields to use radio buttons. That would be fine too. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: authentication data
I agree that there is no one model that fits everyone's needs. Instead, I think it would be nice if the user model to use could be configurable. The admin application currently expects auth User objects, when it should instead expect an object that conforms to an interface, similar to the changes that multi auth brought. One thing that would make this easier, for example, would be to break the permission methods out of auth User into an ObjectWithPermissions class. Now, if I want one of my models to have permissions (like my own user model), then I could simply inherit ObjectWithPermissions. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: authentication data
Chris Long wrote: > The generic auth branch should allow you to create your own custom > permission checking system easily. Well, I'm fine with the system that's already there (or the system that generic auth will be replacing it with). Are you guys also planning on removing the admin application's dependence on contrib.auth.models.User? There are a couple other places in django where contrib.auth.models.User is used directly also. For example, see my previous "multiple authentication and session keys" thread [1]. [1] http://groups.google.com/group/django-developers/browse_thread/thread/851a3f06c5949cb0/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
CharFields and children defaulting to emtpy string
using the example model: class Name(models.Model): name = models.CharField(maxlength=100) when making a new Name object... >>> a=Name() >>> a.save() >>> a >>> a.name '' The name field does not have blank=True or null=True set, but yet I am able to create a new Name object using no parameters (because CharFields and children are defaluting to empty string). Is this the intended behavior? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Are non-critical patches getting enough attention?
Other open source projects seem to have success with Bug Days. Anyone have experiences with bug days? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
gabor wrote: > yes, (unfortunately) it is. > > the models do not validate their input. > > you will have to use a manipulator (Name.AddManipulator) to validate > your input (and then save the object). > > making the models validation-aware is planned, but not done yet. But I am not talking about validating my input here. I just don't want input to be inserted for me. For example, non-specified IntegerField attributes don't defalut to zero. So why then do non-specified CharField attributes default to empty string? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
JP wrote:
> What if widgets could act as filters? I think using filter syntax for
> setting the widget for a field in the template would be pretty
> natural::
>
> {{ form.field }}
>
> draws the default widget for the field type, but if you want to use
> SomeOtherWidget, you can do::
>
> {{ form.field|SomeOtherWidget }}
Or how about template tags for both the default form html and for form
fields (default html or other widget):
{% form form %}
{% formfield form.field %}
{% formfield form.field widget %}
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
Don Arbow wrote: > Yes, from the documentation: > > http://www.djangoproject.com/documentation/model_api/#null > > "Note that empty string values will always get stored as empty > strings, not as NULL -- so use null=True for non-string fields such > as integers, booleans and dates. > > Avoid using null on string-based fields such as CharField and Text > Field unless you have an excellent reason. If a string-based field > has null=True, that means it has two possible values for "no > data":NULL, and the empty string. In most cases, it's redundant to > have two possible values for "no data"; Django convention is to use > the empty string, not NULL." Ok, after some trial and error, I see that if you have null=True on a CharField, it will use NULL instead of empty string. This is what I needed because in my model I have a field that I want to be optional but unique. This is not possible if you don't put null=True for the field because Django will try to use empty string by default. Out of curiosity, any one know for what reason using empty strings for CharFields is the Django convention? Technically, isn't an empty string still data? Isn't it a bit confusing that some fields get default values and others do not? Explicit better than implicit? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
Brantley Harris wrote: > > Another thing to note: In the current Manipulator framework, sometimes > > it is convenient to be able to construct self.fields dynamically. We > > should provide a way to do that with the new syntax. > > +1 +1 Being able to contruct fields dynamically would be great. So if I had a model that stored contacts, for example, it would be nice be able to easily create a form that accepted 3 contacts, or a form that accepted 6 contacts, or a form that shows fields for 6 contacts but only requires 3 to be filled in. This would be similar to the edit_inline and num_in_admin stuff in the admin app. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
David and I have both introduced use cases where defaulting to empty string have caused problems. What are some use cases where an empty string would need to be used instead of NULL? IMO, all FormFields should act the same and default to NULL. If you want the database field to default to something other than NULL, then you can use the "default" parameter in the model's definition. Then, just as you might want to use default=0 for IntegerFields, you might want to use default='' for CharFields. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: I can't mark a ticket as having a patch.
Just FYI, I have noticed that when I try to alter tickets and leave the "anonymous" default for email address, there is a high probability that Akismet will reject it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
Malcolm Tredinnick wrote: > Think about how the data is entered: through a web form (the admin > interface, or a custom form). Now, how do you differentiate between an > explicit empty string and a "no data entered and so it should be NULL" > field? With web entry, you can't, so Django chooses to default to using > empty strings everywhere. So I understand that Django made the choice to default to empty strings, but what I am really trying to learn is why. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: I can't mark a ticket as having a patch.
Linicks wrote: > I have been having issues with Akismet as well. I have submitted a > ticket(http://code.djangoproject.com/ticket/2801), so hopefully someone > will have a chance to look at this issue. Akismet has been blocking my > Wiki updates, but allowed me to submit a ticked without any issues. I > have tried it with "anonymous" and my Wiki settings to no avail. > > --Nick Pavlica Maybe you need to get yourself whitelisted http://groups.google.com/group/django-developers/browse_thread/thread/73adcd35547d150/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Has anyone written an appointment-scheduling calendar template yet?
Carl Wenrich wrote: > I need one that shows the month where you can click on a day and be shown > time slots that you can reserve. I'll probably have to do it in JavaScript, > but I was hoping that something like that was already out there. You might want to ask this in the "django users" group, as the "django developers" group is intended for the development of django itself and has a much smaller readership. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
enable trac's ticket_show_details option?
The ticket_show_details option [1] adds the ability for users to view ticket detail changes in the timeline view. I think this would be nice to have. [1] http://trac.edgewall.org/wiki/TracIni#timeline-section --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Comments system
James Bennett wrote: > My personal preference would be to specify an interface that comments > have to implement, and then let the actual model be whatever the > developer wants; maybe a subclass of django.contib.models.Comment, > maybe not. That feels like it'd give the maximum flexibility, and also > feels a bit more natural in terms of Python -- rather than having to > *be* a Comment, it just has to be able to *act like* a Comment. +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 -~--~~~~--~~--~--~---
Re: Comments regarding QuerySet.valuelist()
I think you raise a valid point. There are valid use cases for both methods. --~--~-~--~~~---~--~~ 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 mail.py Message-ID header
Graham King wrote: > Does this sound sane ? If so I will submit a proper patch. I don't think anyone would turn down the submitting of a patch. I would suggest at least opening a ticket. --~--~-~--~~~---~--~~ 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: Comments regarding QuerySet.valuelist()
> No, I think you're right that we should have a mechanism in place for
> ensuring that methods like this always return results of a consistent
> type. I'm not sure whether it'd be better to do two methods or to
> return singleton tuples, though; anybody got thoughts one way or
> another?
Well, a lot of times, I see myself needing just a simple list (list of
titles, list of id's to pass to in_bulk(), etc.) If we just had a
function that returned tuples, then a list comprehension would still
have to be used to make a list from the singleton tuples when wanting a
for loop or for passing to in_bulk().
With adding both methods, we then have a method for returning each of
the main python data structures. As for valuelist(), instead of being
able to only pass a single parameter, it might be cool to make a zip'ed
list of values, i.e.
>>> list(qset.valuelist("a","b"))
[a1, b1, a2, b2, ...]
--~--~-~--~~~---~--~~
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: 3rd party auth backend access to session object
[EMAIL PROTECTED] wrote: > I want to create a bunch of Session Attributes during login. Mostly > attrs from Active Directory that need to be available without too many > additional calls to the LDAP server. > > User attempts log in -> 3rd party login backend is called -> session is > also passed to the 3rd party backend -> session key[values] are added. > Done. > > I was thinking the session object could also be passed into > authenticate(), but I didn't look at it too long as it would require > hacking up django itself. If anyone else thinks this might be handy, I > will be glad to implement it. > > Right now I make an additional call to the LDAP server after login, but > it is a bit kludgey. Are you using a custom manipulator for your login form? If so, you could pass request when instantiating your manipulator object, and save request as an attribute (through request you have access to the session data) of the manipulator object. Now you run the manipulator's get_validation_errors() method. I assume you are checking the entered password with what's on the ldap server, maybe with a check_password() validator let's say. Since this check_password() validator hits the ldap server, just grab all the data you want and save it to self.request.session at the same time. --~--~-~--~~~---~--~~ 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: doc fixes regarding old forms
Michael Radziej wrote: > Hi, > > there's a ticket (#3005) that fixes bad documentation about writing > forms. It's been closed as wontfix because newforms are coming (and then > re-opened by the reporter). Just for clarification, I re-opened #3005 but I wasn't the reporter. I was, however, the reporter of the original ticket (#2757) concerning the new-admin changes [1] not being used in the forms documentation. > Following the tradition to discuss tickets on the devel-list, I'd like > to ask you to reconsider this policy. The old forms will be around for > months. Patching the docs doesn't bring any dangers for existing code. > The ticket is obviously right, since generic views do it the same way. > The patch is small. I suppose my ticket (#2757) and patch were also passed by since new forms were "comming soon." That was a couple months ago :( > And ... I really can imagine the face of users who fall for the wrong > docs when they find out about the ticket (perhaps when their own tickets > get closed as duplicate?) > > Please, let's strive for correct docs even for changing parts. At least, > when someone is so kind and provides a patch. Yes, correct docs are important. Plus, docs get frozen with each new release, errors included. [1] http://code.djangoproject.com/wiki/NewAdminChanges#ViewFunctions --~--~-~--~~~---~--~~ 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: How do i run just 1 test module?
Curious, does the new testing setup contain any mechanism for running tests for my own applications, say in a package /tests instead of in modeltests/ or regressiontests/ ? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
capfirst and title template filters
Is there a reason why the capfirst and title template filters don't
simply use the capitalize() and title() str methods?
The difference with capfirst is that it capitalizes the first character
without touching the others
>>> Template("{{ name|capfirst }}").render(Context({"name": "DOLORES"}))
'DOLORES'
whereas str.capitalize() will capitalize the first character and also
lower case the others
>>> "DOLORES".capitalize()
'Dolores'
The difference with title is that it lower case the character after a
single quote after a lower case character
>>> Template("{{ name|title }}").render(Context({"name": "de'errico"}))
"De'errico"
whereas str.title() will capitalize both
>>> "de'errico".title()
"De'Errico"
So why the special cases? Should we keep the filters consistent with
their str methods?
lower -> str.lower()
upper -> str.upper()
title -> str.title()
Should we rename capfirst? Or introduce a capitalize filter?
capitalize -> str.capitalize()
--~--~-~--~~~---~--~~
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: capfirst and title template filters
Gary Wilson wrote:
> So why the special cases? Should we keep the filters consistent with
> their str methods?
> title -> str.title()
I did realize an example where the title filter's implementation would
be desired. When you've got a possessive noun:
>>> Template("{{ text|title }}").render(Context({"text": "the boy's blob"}))
"The Boy's Blob"
as opposed to:
>>> "the boy's blob".title()
"The Boy'S Blob"
--~--~-~--~~~---~--~~
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: capfirst and title template filters
Waylan Limberg wrote:
> On 11/16/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> > I did realize an example where the title filter's implementation would
> > be desired. When you've got a possessive noun:
> >
> > >>> Template("{{ text|title }}").render(Context({"text": "the boy's blob"}))
> > "The Boy's Blob"
> >
> > as opposed to:
> > >>> "the boy's blob".title()
> > "The Boy'S Blob"
> >
>
> I think you just answered your own question here. It seems more likely
> that "boy's" would need proper treatment than "de'errico" because the
> name is more likely to already be properly capitalized when entered.
> And with the current filters, as you point out, that proper
> capitalization won't be altered. Hey, if someone types in their name
> wrong, we shouldn't be expected to fix it, or even know how. 'Garbage
> in, garbage out' (tm).
Well, I'm trying to find out what the author is trying to correct here.
There is no comment explaining the special handling. For example, if
the intent is only to correct str.title()'s handling of possessive
nouns, then the regular expression should maybe be r"[a-z]'S\b"
instead.
My main issue with the title filter, though, was that if we are naming
filters the same as str methods, then they should probably be
consistent with the function of the str method they are mimicking. For
example, I believe capfirst filter is rightly not named capitalize
since it isn't consistent with str.capitalize's behavior.
My main issue with the capfirst filter is not really an issue with
capfirst, but rather the lack of a capitalize filter that behaves like
str.capitalize. I have some text that is stored in all caps and would
like to capitalize the first character AND lowercase the remaning. The
capfirst filter does not give me that.
So, I am proposing:
1) Adding a capitalize filter that mimicks str.capitalize.
2) Adding comments as to why the title filter doesn't simply return
the output from str.title.
3) Renaming the current title filter and adding a title filter that
mimicks str.title.
4) Removing the capfirst filter if 1) is implemented.
I'm +1 on 1 and 2.
I'm -0 on 3 since I can live with the special handling, as long as it's
commented. The special handling is probably desired the majority of
the time. Has anyone ever had issues with the special handling?
I'm +0 on 4.
--~--~-~--~~~---~--~~
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: capfirst and title template filters
> The current filters work for me as they are, and I can see how changing > them may cause problems for me (capfirst will not convert an acronym > like NASA to lower case, whereas capitalize will). Yes, I think will all of these that it depends on the data you have to start with. If you have acronyms and lower case text then you would probably want to use capfirst. If you have all upper case text that you want to look nice, then you probably would want capitalize. > But why don't you just create your own capitalize filter (or titlecase > filter) for yourself? Then you'll know that you'll get exactly the > functionality that you need and want. I have no problem creating my own filters, just trying to see how people feel about the str filters. --~--~-~--~~~---~--~~ 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: capfirst and title template filters
On 11/17/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > someone recently complained that str.title() wasn't quite as clever as > text|title > over at comp.lang.python, so I assume that whatever you do, someone will > think it's doing the wrong thing. And that is sort of my point. Is it confusing that text|title doesn't behave the same as text.title()? Having the same names, I would expect them to behave the same. The behavior of str.title can be taken up with the python devs, but as for django, we could at least be consistent. --~--~-~--~~~---~--~~ 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: Custom User/Groups/Permissions...is this possible?
[EMAIL PROTECTED] wrote: > I'm porting another application over to django...while the admin tools > built into django will be nice for some of my tables... I'd prefer to > stick with my old User/Groups/Permissions for a lot of it ... as we > have different users that will be logging in to do different things. > (currently I cannot get the admin feature working anyway... bug? in the > multi db branch that JP is looking into) > > Anyway... If I have my own user/groups/permissions tables...that are > separate from the django ones can I do my own login page...and > store the currently logged in user in the session... then use my old > python code to check their permissions and generate a menu for them > that links to the different views? If so..what is the prefered method > for creating a session and storing data through django? > > Thx If you are wanting users from your own table to be able to log into django's admin interface, then I believe that would require quite a bit of work. The admin interface is very much coupled to contrib.auth's models. If you don't need your custom users to be able to log into django's admin interface, then things a little easier. You could create you own authentication backend [1] that authenticates against your user table. Then, your custom user objects will get stored in the session, you can take advantage of some of the contrib.auth functions (authenticate, login, logout, get_user) and middleware, you can do you own login page, and you can use your old python code for checking permissions, etc. Note, however, that if you plan on running the admin interface you should probably run it with a different server instance with a different settings module; otherwise, you will see clashes because of the admin's coupling to the contrib.auth application (i.e. it expects user objects that adhere to the attributes and methods of the contrib.auth.models.User class). [1] http://www.djangoproject.com/documentation/authentication/#other-authentication-sources --~--~-~--~~~---~--~~ 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: newforms feedback
Adrian Holovaty wrote: > On 12/8/06, Gary Doades <[EMAIL PROTECTED]> wrote: > > Also, how can I pass a validator_list to get similar functionality to > > manipulators? Having the ability to supply a validator_list containing > > a list of small single purpose validators is quite nice. Have I missed > > something? > > As Honza pointed out, you can use ComboField to combine validators > from multiple fields. Alternatively, you can create your own Field > subclass. I realize this is slightly more work than just specifying a > validator_list -- do you think it's OK? I am also a fan of validator_list. As someone mentioned earlier, it is sometimes preferable to have two levels of data validation, at the form level and the model level. I have several cases where I have multiple forms that save to the same model in some way but use different validators. --~--~-~--~~~---~--~~ 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: Default representation of a Form
Lachlan Cannon wrote: > Lakin Wecker wrote: > > as_dl() gets a +1 from me. I've used definition lists for forms and > > prefer it over tables. :) > > Maybe there needs to be an easy hook for people to specify their own way of > laying a form out. It seems the as_ methods are gonna keep growing and > growing. +1 What if instead of adding various as_* methods that we have a FormFormatter class that determines how the form displays. The _html_output and as_* methods would become FormFormatters. Formatter could be a parameter to the Form constructor, and could default to the table formatter like how it is now. This would make Form display with its FormFormatter similar to a form Field and its Widget. This might even be something that would make sense as a setting, default_formformatter. Usually one would not be mixing and matching more than one formatter for a given site. If I wanted to change the display of all the forms on my site, I could make the change in one place instead of having to change all the as_p in my templates to as_my_p. --~--~-~--~~~---~--~~ 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: newforms feedback
Gary Wilson wrote: > I am also a fan of validator_list. As someone mentioned earlier, it is > sometimes preferable to have two levels of data validation, at the form > level and the model level. I have several cases where I have multiple > forms that save to the same model in some way but use different > validators. Just wanted to add that these validators would be run after the Field's clean_XXX has been called, and only if the data was deemed clean. --~--~-~--~~~---~--~~ 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 faster SelectBox.js
graham_king wrote: > If just one person could give it a test, I think there's a good case > for integrating it into the trunk. It behaves like the previous version > but runs faster and the sort works. Without this you can't actually use > the filter interface on more than a few thousand entries. I just tried it out using a select box with about 300 items. Your version seems a tad slower, but it does sort correctly and also fixes #348, so I would take it over the current version. --~--~-~--~~~---~--~~ 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: newforms: generating forms from models enhancements
Honza Král wrote: > On 12/17/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Feel free to take > > on any of the items mentioned in this e-mail, as long as we've all > > agreed on the right way to solve the problems. Rewriting the > > validators to Fields would be a much-welcomed contribution, too. > > Whatever you choose, let us know so that we don't duplicate work. > > see new_fields.py for validators transformed into Fields. It is a > result of a few sed expressions (see gen_new_fields.sh ) and some > manual tweaks. I haven't tested it even for syntax errors, any help > would be welcome, especially tests and documentation (I suck at > these)... > > I will continue working on those whenever I have some time (and mood ;) ) If inheriting Fields is going to be the new validator_list, don't we need to add some super() calls in those clean() methods? --~--~-~--~~~---~--~~ 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: newforms: generating forms from models enhancements
Some more suggestions based on things that I have experienced while recently making an application that required many forms based on models: - Ability to not display certain fields, mainly for when the value will be post-filled in the view (i.e. the owner of an object being set to the logged in user). - Ability to override the default labels and help text, since in some cases the labels and help text presented to an end user should not be the same as what's seen in the admin interface (I believe the label overriding was mentioned already, but help_text would be nice too). - Speaking of help_text, it might be nice for the as_* methods to print this out as well. - Ability to add extra validation to form fields, above and beyond the model's validation. I think this would be satisfied with the "formfield" parameter that Adrian mentioned. These could be satisfied by adding more parameters taking : dictionaries. --~--~-~--~~~---~--~~ 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: newforms: generating forms from models enhancements
Gary Wilson wrote: > Some more suggestions based on things that I have experienced while > recently making an application that required many forms based on > models: > > - Ability to not display certain fields, mainly for when the value will > be post-filled in the view (i.e. the owner of an object being set to > the logged in user). > > - Ability to override the default labels and help text, since in some > cases the labels and help text presented to an end user should not be > the same as what's seen in the admin interface (I believe the label > overriding was mentioned already, but help_text would be nice too). > > - Speaking of help_text, it might be nice for the as_* methods to print > this out as well. > > - Ability to add extra validation to form fields, above and beyond the > model's validation. I think this would be satisfied with the > "formfield" parameter that Adrian mentioned. > > These could be satisfied by adding more parameters taking : > dictionaries. Oh, and I forgot: - Ability to override if a field is required or not. My model might not require data for a certain field, but sometimes I want my form to require data. --~--~-~--~~~---~--~~ 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: newforms: generating forms from models enhancements
Honza Král wrote: > On 12/18/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > > > > Honza Král wrote: > > > On 12/17/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > Feel free to take > > > > on any of the items mentioned in this e-mail, as long as we've all > > > > agreed on the right way to solve the problems. Rewriting the > > > > validators to Fields would be a much-welcomed contribution, too. > > > > Whatever you choose, let us know so that we don't duplicate work. > > > > > > see new_fields.py for validators transformed into Fields. It is a > > > result of a few sed expressions (see gen_new_fields.sh ) and some > > > manual tweaks. I haven't tested it even for syntax errors, any help > > > would be welcome, especially tests and documentation (I suck at > > > these)... > > > > > > I will continue working on those whenever I have some time (and mood ;) ) > > > > If inheriting Fields is going to be the new validator_list, don't we > > need to add some super() calls in those clean() methods? > > > > there are - every clean() starts with > value = ParentField.clean( value ) > which should represent a super call But it's not the same thing. Let's say I want to make a LowerCaseAlphaNumericField that inherits LowerCaseField and AlphaNumericField, both of which inherit CharField. If I were to call LowerCaseField.clean() and AlphaNumericField.clean() from my LowerCaseAlphaNumericField.clean(), then CharField.clean() and Field.clean() would both get called twice. If I were to use a super call in my LowerCaseAlphaNumericField.clean(), then LowerCaseField.clean(), CharField.clean(), and Field.clean() would get called, but not AlphaNumericField.clean(). Everybody must use super so that all the correct methods get called and get called only once. I'm not sure where ComboField fits into this either. Is ComboField supposed to be used instead of inheritance for building validators? If so, then ComboField suffers the same fate of calling clean() methods of inherited Fields more than once (even if super calls are used) because ComboField.clean() simply calls every passed Field's clean() method. --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
I often find myself writing code like: try: user = User.objects.get(pk=user_id) except User.DoesNotExist: user = None What do you think about adding a get_or_none QuerySet method? def get_or_none(self, **kwargs): try: return self.get(**kwargs) except self.model.DoesNotExist: return None --~--~-~--~~~---~--~~ 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: Customizable object tools
FYI, I filed a ticket [1] about this same topic last week, but I was asking for an extra block tag in the change_list template. I am assuming that you are also putting the object_tool_links on the change_list page? Looking at my ticket again, I am thinking it would be better to put the block tag in the admin/base_site.html template, that way any other page extending admin/base_site.html could add custom object tools instead of just the change_list page. As for your suggestion, what if you wanted to put object tools on the change_form page too? It's starts to get messy with adding Admin class attributes for each of the pages. Probably more elegantly handled in the templates. [1] http://code.djangoproject.com/ticket/3128 --~--~-~--~~~---~--~~ 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: Customizable object tools
Gary Wilson wrote: Looking at my ticket again, I am thinking it would be better to put the block tag in the admin/base_site.html template, that way any other page extending admin/base_site.html could add custom object tools instead of just the change_list page. I meant admin/base.html. Added new and improved patch to ticket. http://code.djangoproject.com/ticket/3128 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#2473 - 'in' QuerySet operator generates invalid SQL for empty list
Patch and a few tests added. Can someone please review and test on something other than postgres. http://code.djangoproject.com/ticket/2473 --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
SmileyChris wrote: On Dec 19, 11:08 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > something like this: > > user = User.objects.get(pk=user_id, default=None) Except this would break (or at least limit the functionality of) objects which use "default" as a field name. Of course, this didn't stop get_or_create(), which uses "defaults" as a parameter. If you had an object with an attribute named "default" then you could still do something like: obj = MyModel.objects.get(default__exact=42, default=None) But get_or_create() was new functionality and this would be changing existing functionality. If that is unacceptable, then maybe a get_or_default() that optionally takes the "default" parameter, using None if no "default" specified. So... MyModel.objects.get_or_default(pk=1) would be equivalent to MyModel.objects.get_or_default(pk=1, default=None) --~--~-~--~~~---~--~~ 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: Customizable object tools
Ville Säävuori wrote: Replying to myself > This would be great. But I think it would be better to name the > templates __foo.html. It would make the customization of > admin pages very easy and Django-like. D'oh. After looking the admin source code, this allready works! I wonder howcome it isn't documented? (Or is it?) Anyway, you can override the default admin template (at least for change_list.html and change_form.html) by putting your own template to /yourtemplates/admin// for app-wide override or to /yourtemplates/admin/appname/modelname/ for model-wide override, respectively. This is great. And I really think it should be better documented! :) Yeah, the only place I know of is: http://code.djangoproject.com/wiki/NewAdminChanges#Adminconvertedtoseparatetemplates --~--~-~--~~~---~--~~ 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: #2473 - 'in' QuerySet operator generates invalid SQL for empty list
Russell Keith-Magee wrote: If you can get some confirmation that this approach works on other backends, I'll put it in as an interim measure; and if nothing else, the tests are most helpful - Thanks for those. Installed mysql 5.0.26, and the tests passed. --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
Joseph Perla wrote: There should also be an update_or_create() function. I often find myself get_or_creating, then updating the object's dict if it wasnt just created, then saving. This can easily be expressed more clearly in one line with this function. This gave me the idea of an update() method for model instances. I have created a ticket for this with code, documentation, and tests. http://code.djangoproject.com/ticket/3180 --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
Joseph Perla wrote: Also, here's the pseudo-ish code for it: def update_or_create( --same arguments as get_or_create()-- ): object, created = Class.objects.get_or_create( --args above-- ) if not created: object.__dict__.update(defaults) object.save() return object Well, Class is self or this or whatever it is in python/djangomanagers code. I'm also not sure how to do the crazy **kwargs stuff. The rest is clear: if you didn't create it, just update it, save it, and return. I have created a ticket for this too and have attached some code: http://code.djangoproject.com/ticket/3182 --~--~-~--~~~---~--~~ 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: newforms error design
[EMAIL PROTECTED] wrote: But in fact it does not look user intuitive. I concur with this statement. I've got a form with about 10 fields and when there are multiple errors for adjacent fields, it's very hard to tell if the error is for the field above or below. The problem is visual. I do not like to present end users so ugly looking errors. As temp. solution I have patched as_table() output, so it takes optional argument: errors_on_separate_row -0 My vote would be to change as_table() to make it more pleasing to the eye rather than introduce a parameter. The errors on a seperate row is pretty unusable and we should not allow the creation of such forms in Django :) --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
Gary Wilson wrote: I have created a ticket for this too and have attached some code: http://code.djangoproject.com/ticket/3182 Documentation and tests attached too now. --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
Jacob Kaplan-Moss wrote: Hm - I get a whole bunch of failures when I apply the patch. Looking closer, you say it depends on an ``update()`` patch in #3181, but I don't see any such patch attached to #3181. Sorry about that, it should be #3180. Can you update #3182 to include this other patch (wherever it lives), and close the other ticket as a dup of #3182? Once that's done I'll go ahead and check this in. Well, the two tickets are different functionality. I could create a single patch for both, the only thing was that in the patch for #3180 I added an "Updating objects" to the db api documentation, but then realized that it should probably be integrated into the "Saving changes to objects" section. I haven't spent the time to do that yet. --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
Jacob Kaplan-Moss wrote: On 12/24/06 11:15 PM, Gary Wilson wrote: > Well, the two tickets are different functionality. I could create a > single patch for both, the only thing was that in the patch for #3180 I > added an "Updating objects" to the db api documentation, but then > realized that it should probably be integrated into the "Saving changes > to objects" section. I haven't spent the time to do that yet. Yeah, they're different... but I think they make the most sense if they go in as a unit. I'd prefer a single patch (and tests, docs, etc.) if you're up to it. Sure, I'll work on the documentation fixes and let you know when done. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
