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...
> > 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
I know that for some of these the order in this list's is important.
So maybe a new way of specifing/adding suff to these settings has to
be defined.
But I think it would help if an application can define which
additional middlewares or context precessor it uses. This would make
the application itself more self-contained.
> > 3. Develop some kind of explicit way that apps can declare
> > dependencies on other apps so that apps can just be dropped in with
> > any dependencies, their prefixes set, and they be good to go.
>
> I think this is possibly best solved by just importing the other
> applications in __init__.py. That way, "manage.py validate" and any use
> of the application will fail at the very first import. So if my weblog
> app depends on my tag app, putting "import tagging" in
> weblog/__init__.py enforces the dependency.
>
> Just my personal feeling, but I think using Python's built-in dependency
> enforcement like this is preferable to adding any extra infrastructure
> to Django. I can't imagine we could do anything that would be much more
> simple than "import foo" without imposing a burden on the app developer.
I agree that using the python import as a dependency enforcement is a
good thing, as long as there are dependencies to other `applications`.
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...
Just m2c,
Martin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
