On Wed, Sep 1, 2010 at 1:24 AM, stefanw <stefanwehrme...@gmail.com> wrote: > Hello, > > I guess the most interesting point in this discussion is: > >> After a while that I spent time to develop new tags and filters >> especially for >> new projects, I began to think a way to implement a template engine >> that >> would let me no more write sort of "plugins" like tags and filters, a >> thing that >> really bother me. > > The template language is great, it's design decisions are sensible, > but writing filters and tags is too complex and time-consuming. > Unnecessarily so, as wrappers around creating template tags have shown > (e.g. django-templatetag-sugar by Alex Gaynor). If people don't see a > documented way of easily bringing features to their templates, they > may switch the template engine or, well, start patching the template > engine. > Bottom line: we need to improve the template tag creation.
You won't get any disagreement from me (or, I suspect, anyone on the core team) about this. Where argument emerges is on the best way to solve the problem. There are several projects like Alex's that provide ways to "fix" template tags. There has also been a recent proposal to add a shortcut specifically for the "invoke callable, store as variable in context" pattern. It's worth noting that about a year ago, a similar situation existed for session based-messages. There were half a dozen projects implementing session-based messages as a third-party app, all with a slightly different take on the problem. What changed was that someone (Tobias McNulty) decided he wanted to resolve the situation, and drove the issue forward. He put up a wiki page [1] that gave a thorough summary of the issues and candidates, and got a discussion going on django-dev about the idea. He worked on an integration project to get the best aspects of all the candidates into a single codebase, and within three months, trunk had an implementation of session-based messages. There is a splendid opportunity for someone to do the same thing here. There is clearly a desire to improve the process of writing template tags. There are many candidates on the table, each with a different approach to the problem. What is needed is for someone to drive the discussion to determine the features we (as a community) want in trunk, and prepare the final candidate for merging. [1] http://code.djangoproject.com/wiki/SessionMessages Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
