Thanks, Panos. Just took a quick look - the settings context processor is useful, but still requires explicit addition into each view using that template.
The generic_content tags fit my examples, and probably for most use- cases, but I don't know... I'm not comfortable in putting logic that specifies how and what to pull out of my data into the template; that stuff should sit within my view code. In something unrelated, the markup formatter in that project seems useful for what I'm doing, so thanks for pointing it out. Sam On Dec 30, 2:05 am, Panos Laganakos <[EMAIL PROTECTED]> wrote: > Check out Django Template Utils[1], it will probably fit your needs. > > [1]http://code.google.com/p/django-template-utils/ > > On Dec 29, 5:42 pm, Sam Lai <[EMAIL PROTECTED]> wrote: > > > > > Thanks Alex and hedronist. I'm leaning towards creating a generic > > template tag that loads template context processors to do this (I > > don't have the complicated needs you had hedronist... as far as I > > know). > > > I was just wondering if there was a 'best-practice' way of doing this; > > looks like creating template tags is the way to go. It's probably > > worth having a look at building a generic template tag for this into > > django, given this is a fairly common problem. > > > Thanks! > > > Sam > > > On Dec 29, 12:01 am, hedronist <[EMAIL PROTECTED]> wrote: > > > > > The other approach I've seen from James Bennett's blog, is to create a > > > > template tag to retrieve model data generally. This works too, but it > > > > feels like it's more legwork that should be required. > > > > We ran into this problem on a site we just launched. We tried several > > > approaches but ultimately went with templatetags. Our most involved > > > case was where a page contained one or more boxes of information which > > > needed to be populated based on some moderately complex rules of user > > > membership level, object premium level, object type, subject category, > > > etc. At the template level it looked deceptively simple: > > > > {% selector <selector_name> as <var_name> %} > > > > Behind the scenes, this fetched a rule set, determined the matching > > > objects, cached the result, and returned a dict of arrays of objects. > > > > Sigh. The client got exactly what they wanted (in fact, demanded) but > > > they ultimately descended into choice overload and fell back to a > > > simple override scheme where they simply gave a list of objects for > > > each box. Getting the selector code and admin interface right took > > > many hours, but what they actually ended up using could have been > > > coded in 30 minutes. Meh.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
