On Thu, 2008-07-10 at 20:38 +0530, Amit Upadhyay wrote:
> 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 t
+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
Hi Amit,
On Thu, Jul 10, 2008 at 6:08 PM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> 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.
I've done this in my company's mercurial repo of django. It works
well, and allo
2008/7/10 Amit Upadhyay <[EMAIL PROTECTED]>:
[...]
> 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 creat
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 de
