Charles Choiniere wrote: > On Mon, Sep 22, 2008 at 10:46 AM, Norman Harman <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > nek4life wrote: > > How would I go about getting a queryset into an include? Say I > have a > > blog and I have a page for the post detail. On the sidebar I would > > like to have the blog categories dynamically built or have recent > > articles, or recent comments, etc... What would be the best approach > > to build these "widgets" for use on multiple pages? Any help > would be > > much appreciated. Thanks. > > Custom Template Tags? > > http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-template-tags > > > -- > Norman J. Harman Jr. > Senior Web Specialist, Austin American-Statesman > > ___________________________________________________________________________ > Get off the sidelines and huddle up with the Statesman all season long > for complete high school, college and pro coverage in print and online! > > > > I was looking at that and found the inclusions tags and that looks like > what I need, however I'm a little unsure about where to put this > function. Would I put this in the model I want to pull the data from? > I haven't extended the templating system before so I'm a wee bit confused.
http://docs.djangoproject.com/en/dev/topics/templates/#custom-libraries-and-template-inheritance http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-template-tags "The app should contain a templatetags directory, at the same level as models.py, views.py, etc. If this doesn’t already exist, create it - don’t forget the __init__.py file to ensure the directory is treated as a Python package. Your custom tags and filters will live in a module inside the templatetags directory. The name of the module file is the name you’ll use to load the tags later, so be careful to pick a name that won’t clash with custom tags and filters in another app." Saying all that, depending on what you're actually doing, putting the actual "logic" into a method on a model that the template tag calls (as opposed to putting the logic in the template tag itself) might make sense. In other instances it might not. Very general rule: If it's doing display/formating type stuff put it in the template tag. If it's doing db stuff, calculations based on model fields, proly should be in the model. This is a core of OO & MVC. each layer/object should do it's thing and not get involved in what other layers/objects are doing. -- Norman J. Harman Jr. Senior Web Specialist, Austin American-Statesman ___________________________________________________________________________ Get off the sidelines and huddle up with the Statesman all season long for complete high school, college and pro coverage in print and online! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
