google groups gobbled my response and I don't see it...sorry if this turns out to be a repost.
On Apr 10, 12:26 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 4/10/07, Martin J Hsu <[EMAIL PROTECTED]> wrote: > > > > > I saw this as a minor inconsistency in how settings are defaulted. > > Not a big deal to me personally. Django was made by perfectionists > > and I thought I'd point this out. > > Django-admin produces a default settings file that contains the most > common user-specified settings. There are _many_ other settings, all > with reasonable default values, that are documented and available for > the user to override if required. I'm afraid I don't see the > inconsistency. > I was wrong, it's not inconsistent. It seems to be a somewhat popular setting. From reading in this news group, people seem to need help with this. It seems that all the needed settings are right there in settings.py (thus the illusion of consistently having everything needed present). Having the default might help some people w/ the context. Again, I'm not an expert and I'm just offering an opinion from my perspective. > > I don't know if this is the appropriate place/time/etiquette (please > > tell me if this is inappropriate), but I made a simple change to > > implement this behavior: > > Regarding ettiqette - small patches like this are ok, but larger ones > should generally be attached to a ticket describing the feature > request. > Thanks for the clarification. > As for the change itself - I just don't see why this is required. As > you point out, what you are trying to achieve (derive context > variables from the request) can be done by defining a context > processor. > Firstly, I never said it was required (we've already established that it is redundant). Secondly, you cut out the part where I explained why I think it wouldn't be such a bad thing. Maybe it wasn't clear, I'll try to expand on that below. > What you are proposing would complicate the convenience mechanism of > allowing simple callables in extra_context, in the name of duplicating > functionality that is already possible by defining a context > processor. Why is this a desirable change? > I'm sorry, but I don't see how this complicates anything. Nobody is forced to change their current or future code. Unless I'm missing something, it is 100% backward compatible w/ the way things are now. There is a little bit of extra overhead should the callable not be defined w/ the request variable and an exception thrown and the callable is dispatched w/o an argument. Duplication of functionality already partially exists. I've already inquired about why. Your response was: 'to make the simple case of deferred evaluation trivial to implement.' That makes sense and I think expanding the usefulness by adding a request variable is reasonable. In addition, people who use the book as a guide, will be introduced to generic_views and then might need to expand their utility. Thus, it might not be strange for them to come upon the docs that explain the 'extra_context' parameter. Maybe they would think, 'hmm, this is convenient, but it would be nice to have the request. I guess I'll ask the mailing list how this can be done.' This is precisely how I started looking at this. What I'm put forth for discussion isn't being done in the name of duplicating function. Rather it is to expand on the convenience of this mechanism, which exists to serve a very reasonable purpose. I think it would make Django better for some without disrupting everyone. That might be enough to make it desirable. > > ). Can you get a timestamp from an HttpRequest? > > No, because it isn't a property of the request. > Thanks again. > > I definitely see that as a difference in the overhead. With that in > > mind, wouldn't having a built in tag (part of the template language > > proper) be a good solution? After all, it's just a call to > > time.localtime() or such. > > You mean, something > like:http://www.djangoproject.com/documentation/templates/#now > ? > Yes. That's exactly what I was looking for. I searched through a few places for 'timestamp' including one of the template docs, but didn't see that. Thanks. > For example, you could put 'datetime.now' as extra context, and the > template would be provided with the evaluated value - the current time > and date. That would mean that this common-use case is less than optimal. > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
