The advantage is you get to organize your additions in the base
template (which is where you should strive to manage layout & L&F as
much as possible). Your solution works fine for a row-by-row example,
but is less flexible for a more complex layout. For example, if you
want to have a two- or three-column view, it is easier to manage this
by changing it once in the base template than trying to tweak the view
function. What's more, portals are often associated with "skins" - it
would be much more flexible to have the choice of a few "base"
templates (representing different skins) with completely different
layouts for the "sub" templates. If you were looking for a generic
solution, I think you should consider that.
Not sure about how the "specific template" would fit in there
though... but I don't see major limitations with the approach I
described vs. your original proposal. In a case where you can't
generalize the view you probably want to save it as an html snippet in
the database, I suppose.
-rob
On Jun 2, 11:16 am, "patrick k." <[EMAIL PROTECTED]> wrote:
> what´s the advantage of including the sub-templates in the template
> instead of rendering them in the view?
> rendering the templates in the view seems to be a bit more flexible
> when it comes to caching, I guess.
>
> besides, a custom entry could have its own specific template - so, I
> ´m not sure how you´d deal with this.
>
> thanks,
> patrick
>
> Am 02.06.2007 um 20:07 schrieb oggie rob:
>
>
>
> > Using the "include" tag, you can provide the template through a
> > variable
> > e.g. {% include template1 %} instead of {% include 'mysite/
> > movies.html' %}
> > so you can pass this stuff from the view.
> > What's more, the include template uses the context from the "parent"
> > template. So you can also pass all this information from the view.
> > For example, your view could work as follows (code is littered with
> > mistakes but you should get the idea):
> > def my_portal(request, user_id):
> > template_list = get_portal_template_list(user_id) # returns list
> > of strings, representing template names
> > data = {'templates':template_list}
> > for template in template_list:
> > data.update(get_template_data(template, user_id))
> > render_to_response(data, "base_template.html")
>
> > in base_template.html
> > {% for item in template_list %}
> > {% include item %}
> > {% endfor %}
>
> > You may also organize & test a little more using the "with" tag (it
> > appears to works alongside "include"). e.g (with a modified view):
> > {% for item in template_list %}
> > {% with item.data as data %}
> > {% include item.template %}
> > {% endwith %}
> > {% endfor %}
>
> > then in the included template:
> > {{ data.field1 }}
> > {{ data.field2 }}
>
> > HTH,
> > -rob
>
> > On Jun 2, 4:51 am, patrickk <[EMAIL PROTECTED]> wrote:
> >> This is a problem we´re having with every webpage we did with django
> >> so far.
> >> Now, I´d like to make this more generic and write a tutorial for how
> >> a portal-like page could be done using django.
>
> >> As an example, let´s say we have a database with movies, stars
> >> (actors, writers, directors ...), cinemas/theatres, interviews,
> >> image-
> >> galleries, trailers, filmfestivals, ...
> >> Now, the editors should be able to "build" a page (e.g. the front-
> >> page) with different blocks of content like:
> >> 1. a single object (e.g. a movie, star, interview ...)
> >> 2. combined objects: a combination of x objects (e.g. "godard-
> >> special" with a relation to a star (godard), a cinema where the
> >> special takes place and several movies)
> >> 3. pre-defined blocks (like "recent comments", "recent interviews",
> >> "most discussed movies" ...)
> >> 4. custom entries
>
> >> ### 1 and 4 is easy: for 1, we can use a generic foreign key. for 4,
> >> we´re using a second table ("custom entries") and also a generic
> >> foreign key - so 1 and 4 is basically the same.
> >> ### For 2, we could also use the table "custom entries", but with a
> >> second table "custom entries item" for the (multiple) generic
> >> relations.
> >> ### for 3, we could either use template-tags or custom methods.
>
> >> The models are here:http://dpaste.com/hold/11537/
> >> And the view is here:http://dpaste.com/hold/11538/
>
> >> So, the question are:
> >> 1) Could this be done easier or more generic?
> >> 2) How and where to define the custom methods?
>
> >> With the given models, we could construct a page like this:
> >> #1 Movie Nr. 1234
> >> #2 custom method "Recent Comments"
> >> #3 Interview Nr. 3456
> >> #4 Custom Entry "Godard-Special" (a custom entry with relations to a
> >> star, a cinema and several movies)
> >> #5 custom method "Get Banner"
> >> #6 Star Nr. 789
>
> >> Note: The templates could be saved to the database for making editing
> >> easier (although I personally don´t like storing templates within a
> >> database).
>
> >> It´d be nice to see this issue solved in a resusable manner. To me,
> >> it seems a bit complicated the way we´re doing it right now.
> >> Comments and Feedback is much appreciated ...
>
> >> Thanks,
> >> Patrick
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
