On Wed, 23 Nov 2005 17:19:20 +0000 Robert Wittams wrote: > * Come up with a standard pattern whereby template tags > provide a method to extract things out of the request, > do some processing and stuff it in the context. > The method must be called in in your view function > + uncoupled > - makes overriding templates to add a stateful tag impossible > - repeating yourself - each stateful tag must be mentioned in > the view and the template
A slight variation is to call the method via your urlconf, and this then boils down to something like http://code.djangoproject.com/ticket/779 . The difference is that these tags can then be used by generic views. I'm leaning slightly more towards this option now. It means that the pattern for custom tags that need the request object is to have a helper function which actually processes the request, and this will help separate any processing of the request from presentation of the results. You then have the concept of a web page component/control that has a processing phase and a presentation phase. If you think about it like that, it doesn't seem like repeating yourself so much. With the view/template methodology, you have to deal with your data twice -- you put it into the context, then get it out, repeating at least the name of it, and if you do any complex pre-processing you may even have to loop over it twice. You don't have that repetition with a naive PHP application, but we think Django's way is much better -- we call it separation of processing and presentation. Luke -- "Pessimism: Every dark cloud has a silver lining, but lightning kills hundreds of people each year trying to find it." (despair.com) Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
