On Sat, 2006-07-29 at 19:49 -0500, Martin Glueck wrote:
> Malcom,
>
> I'm pretty new to django, so please forgive me if I missed something.....
>
> > However, that doesn't take care of the reverse URL mapping, as you
> > indicate above. Work on that area is being done by Adrian with his
> > reverse URL mapping stuff (there have been some commits on this
> > recently, too), including a template tag to allow templates easy access
> > to this information. Over time, we will no doubt enhance and extend the
> > initial work to accomodate more and more deviously twisted ... er...
> > important use cases. So, whilst this point is probably the most limiting
> > of the three you mention, it is also, fortunately, the one that is
> > having some real brain power applied to it.
>
> Can you give me pointer to this new template tag? becasue this reverse
> url maping is one of my current problems and I'm not really happy the
> way I implemented it right now...
This is still work in progress. Unfinished as yet. I don't think the tag
exists yet, but the django.core.urlresolvers.reverse() and
django.db.models.permalink() methods are part of this.
> > > 2. Allow each app to optionally specify a context_processor(request)
> > > function in their __init__.py file. By default, all the context
> > > processors that exist would be called in the order that the apps are
> > > listed in the INSTALLED_APPS attribute. Obviously, this could be
> > > dangerous because apps could try to define different values in the
> > > context using the same key. Maybe we could do some kind of fake
> > > namespacing ( {{ app.key }} to avoid that.
>
> Using the `include` for the url-config allows to decouple the
> application from the url it is `installed` to (assuming that the
> reverse mapping issue is solved).
> But I would like to see a simmilar approch for some other `settings`
> as well, like
>
> TEMPLATE_CONTEXT_PROCESSORS
> TEMPLATE_DIRS
> MIDDLEWARE_CLASSES
TEMPLATE_CONTEXT_PROCESSORS we talked about earlier and that probably
does bear more thinking about.
TEMPLATE_DIRS is for project-wide templates, so I'm not sure why an
application would want/need to change that. If you depend on some other
template being available, there should be a way to say that (although a
re-usable app is normally not going to do much beyond extending
base.html or something). Uf you supply templates, then they are in your
own template directory and will thus be available as soon as the app is
installed. Installing templates outside your own application is probably
not particularly maintainable. It is necessary in those cases to follow
something like the directory hierarchy from [1], since otherwise
template name clashes result.
[1] http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters
MIDDLEWARE_CLASSES is a tricky one. My gut feeling is to say we should
explicitly install stuff in there, because it is *very* order dependent.
But it needs more thought, because until you posted this, I, for one,
hadn't considered programmatic changes to that list. We might need to
tweak the middleware processing hierarchy slightly anyway (there are a
couple of tickets open about this; making it more stack-like,
essentially), because there are some slightly flaws in the way it works
currently. Something to keep in mind for when we do that.
[...]
> But what still is missing is a way to express which additional
> `templatetags` an application needs.
> I have only started working with django a few weeks ago, but one of
> the first thing I noticed is that defining new template tags makes
> writing yout templates way more easier...
> And currently you don't have an possibilty to specify what addition
> templatetag `libraries` an application needs (besides the `load` in
> the templates itself).
> And since I normaly don't look at the templates that much, it would
> help if this dependancy could be expressed in the `application` as
> well...
You can do this already, I suspect: Template tags are imported through a
"load" tag in the template. The file that is loaded must be an
importable Python file. So I think it would work to specify this as for
other applications -- "from other_app.templatetags import special_tags"
-- already. Have I overlooked a problem you have in mind here?
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
