+1 for the main proposal and subproposal (modulo concrete syntax).
Decoupling template library imports from app_label would also be good
for #3591. Get rid of as many app_label dependencies as possible.
Beautiful languages such as php and c have flat namespaces - don't go
there.
Concerning your subsubproposal: strictly only {% load %} would be
essential. So the separation would be mostly arbitrary. Just allow
libraries to shadow existing tags/filters.
(For those dismissing django.template features because of non-
programmer/designer/beginner use-cases: there already are quite a few
possibilities to shoot yourself in the foot, and I'd bet the template
language is turing complete.)
Am 10.07.2008 um 17:08 schrieb Amit Upadhyay:
> Hi,
>
> I have identified a few issues over the time that makes working
> with custom django template tags/filters a little less than ideal
> for me.
>
> My chief problem is: if I see an unknown/unfamiliar tag/filter and
> want to locate the exact code responsible, I have to do the
> following: find all loads defined in the template, for each of
> those "loaded template libraries", I have to find the py file by
> searching it in all INSTALLED_APPS/templatetags folder and then
> scanning them for a register_tag/register_filter call with the
> unknown name. This to me is a little bit too much magical[PS1].
> Further, what if there are more than one apps with some_template.py
> in their templatetags folder? And why is it called templatetags
> when it can have both filters and tags? (*tongue in cheek remark :-).
>
> Bottom line is clean namespacing is difficult to achieve as of now,
> but would be possible with the following "syntax":
>
> {% load mytemplatelib.few_tags as cool_tags %}
>
> and used subsequently as {% cool_tags.show_something %}. Or the
> alternate syntax:
>
> {% load mytemplatelib.few_tags.* %} and I can do {% show_something
> %} [this sytax would come with its warning similar to the ones
> issued against using the "from django import *" like imports in
> python].
>
> Note: mytemplatelib.few_tags would be search in sys.path and not in
> installed_apps' templatetags folders.
>
> As a template writer I will have to provide a module
> mytemplatelib.few_tags with a show_something named function which
> acts as a tag. There would be some decorators/protocol to tell if
> they are valid tag/filter.
>
> Assuming the idea is accepted, It can be implemented in a mostly
> backward compatible fashion, post 1.0, either by having a {% import
> %} named new loader for 1.x, or even {% load %} name can be
> preserved as one can first look into the old way of loading and if
> it fails can look for new way.
>
> This has been discussed before[1], but I have some objections with
> the latest implementation[2]:
> * appname/templatetags still persist, and is the place where
> libraries will be looked into, there is no reason for django to
> enforce and create its own import paths, PYTHONPATH, sys.path etc
> are good enough for that. Let application developers and
> templatetags library writer pick what makes sense. Looking into
> INSTALLED_APPS constraint does not buy much and can be cleaned up
> entirely.
> * We still have to do the search if we get a new/unfamiliar
> template tag/filter. This is just not pythonic to me.
>
> Both these are backward incompatible changes, but like I said
> current way can be kept, with some DepricationWarning, and 1.x may
> include the new way which looks for module name in sys.path instead
> of app_name/templatetags/.
>
> Subproposal:
>
> Add settings: DEFAULT_TEMPLATE_EXTENSIONS [avoiding the words tags/
> filter as it can be either], being a list of strings that will be
> automatically be {% load whatever %} in all templeates.
>
> Subsubproposal:
>
> Split defaultta
> gs into defaulttags_essentials which will include tags like "load",
> "extends", "block" etc, which are really required for templates to
> work vs others like "for"/"if" and the rest into some other module
> that gets added by default in
> "settings.DEFAULT_TEMPLATE_EXTENSION". So that if I can use the
> fancier versions of my template tags/filters by turning off the
> django ones and using just mine, without having to use any
> namespace prefix, and without having to worry abt conflicts with
> django's default template tags/filters.
>
> PS1: Though there is nothing stopping me from writing a script that
> takes the tag/fitler name and returns me the qualified name of the
> function handling the tag/filter.
> [1]: http://groups.google.com/group/django-developers/browse_frm/
> thread/2b5a4a31f0349d27/b92c96a8dccc214b#b92c96a8dccc214b
> [2]: http://code.djangoproject.com/attachment/ticket/2539/
> patch_2539_code_tests.diff
>
> --
> Amit Upadhyay
> Vakow! www.vakow.com
> +91-9820-295-512
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
