this is just another request for feedback. I know that there are some
newspaper-sites out there, made with django. so, I assume, they´ve
solved this issue. It´d be great to know how they make/construct the
overview- resp. front-pages (in a way to make changes easily for
editors).
thanks,
patrick
Am 03.06.2007 um 19:28 schrieb oggie rob:
>
> 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
-~----------~----~----~----~------~----~------~--~---
