On Dec 7, 8:25 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-12-05 at 11:55 -0600, Jacob Kaplan-Moss wrote:
>
> [...]
>
> Jumping in a little late here, but the things I remember thinking about
> (and discussing briefly with Adrian when he described his plan to me) is
> that app_label collisions are often only the tip of the iceberg in some
> respect. They also tend to be an indicator of upcoming template
> directory name collisions -- for example if you use the
> templates/<app_name>/* convention -- and custom templatetag name
> collisions.
>
> None of those problems are in any way insurmountable, but we need to
> think through what will work practically for those situations. For
> example, the template app_loader, if it remains, should not use the
> "label", in Adrian's scheme, to load the template because that would
> mean an application cannot load its own templates (it won't know what
> its own label will be because that is set by the user at installation
> time and unknown to the app writer). I think we're probably fine here:
> app_loader continues to just merge all template directories at the top
> level and application writers still strive for unique names for their
> template directories (or stop using app_loader, which is something I've
> been tending towards more and more lately).
>

I agree that these issues need to be thought through. A related issue
(mentioned elsewhere on this thread) is whether you could have
multiple app instances with the same code but different labels: should
this be allowed/disallowed/checked for? As for standard template
loading, there's no reason that the standard template loading
(app_loader) code could not be modified to work with App instances,
using whatever logic to use the application path and/or label to
locate the templates. Or have I misunderstood Malcolm's comment?

Regards,

Vinay Sajip
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to