> I haven't done exactly this, but I've done something similar, and can
> maybe help with some general principles.
Hi Eric. Thanks for the help and advice!
> It's not clear exactly what's going into these pods, but it's usually
> a bad idea to have things like 'style' or 'placement' in the database
> tables: that's presentational logic, not data. I would suggest either
> {% include %}-ing smaller template snippets, or using custom template
> tags. If the snippet/tag can get all its information from the existing
> context, use an include; if it needs its own database queries/extended
> python, use a tag.
Honestly it's not completely clear to me, either. That could be part
of the problem :)
I was trying to make a relatively simple CMS to get to know django
better. I'm loosely recreating a "website builder" app that would
allow non-technical users to edit and update their websites. The
"pods" could be thought of as content blocks or banner ads or
something similar. Incidentally, I don't call them "pods" in the
application, but for the sake of clarity, I wanted a name that didn't
include "block" or "node." That's the best I could do on short
notice.
As for presentation vs. data, I understand your point.
> Still kind of shooting in the dark: information such as how the pods
> are to be displayed should probably come in through the view. Maybe
> via a GET query, maybe via saved user settings. You could create a
> dictionary in the view, where say the keys were snippet/tag names, and
> the values a list of style/presentation parameters that were passed to
> each appropriate snippet. Something like that. Then your template is
> simply a matter of checking if the dict has certain keys, and then
> using the dict values to populate CSS style attributes, or to set
> variables telling a template tag which queries to perform (actually
> that last might not work, can't remember...).
As you can probably tell, I was trying to get by with the least work
possible and that usually spells disaster. I figured I could call
everything with Page.objects.select_related(), and then have the
template sort out the details.
Interesting that you bring up the custom dict - that's what they seem
to do here:
http://www.carthage.edu/webdev/?p=15
> As always, B-List has the
> goods:http://www.b-list.org/weblog/2006/jun/07/django-tips-write-better-tem...
>
> Hope something in there helps,
That's what I started to read before I made my first post. Guess I
should review it :)
Well you got me thinking a little harder! Thanks again!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
