Ahh, yeah, I suppose so! I didn't really think the rendered text
through, and you're right that it has the same flexibility.
-rob
On Jun 3, 2:40 am, "patrick k." <[EMAIL PROTECTED]> wrote:
> actually, I don´t have to change the view for whatever layout I want
> to have with my approach ...
>
> patrick
>
> Am 03.06.2007 um 00:40 schrieb oggie rob:
>
>
>
> > 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
-~----------~----~----~----~------~----~------~--~---
