best practice for portal-like pages?

[patrickk]

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

[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

[patrick k.]

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

[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

[patrick k.]

actually, I don´t have to change the view for whatever layout I want
to have with my approach ...

patrick

[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

[patrick k.]

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

[omat]

I am also in need of such a flexible yet easy to manage content
system, mostly for small company websites.

In my primitive prototype, I have pages that are built-up of sections.
Each section has its own template and can hold text, images, etc.
Also, I am planning to add the ability to display data dynamically
form another application.

I am not willing to write the content administration part, but this
flexibility makes it very hard to manage content using the built-in
admin application. For example, a 50 page website with 10 sections per
page on average shows up as a list of 500 sections, which is not very
practical to manage.

That's why I am not very satisfied with my application and would like
to hear from others about this.

There is nothing fancy about my model but just for reference, here it
is:

class SectionType(models.Model):
name = models.CharField(maxlength = 50)

def __str__(self):
return self.name

class Admin:
pass

class Section(models.Model):
type = models.ForeignKey(SectionType)
title = models.CharField(maxlength = 150,
blank = True)
body = models.TextField(blank = True,
null = True)

def __str__(self):
return '%s (%s)' % (self.title,
self.type)

class Admin:
pass

class SectionImage(models.Model):
section = models.ForeignKey(Section,
edit_inline = models.STACKED,
null = True)
image = models.ImageField(upload_to = 'section/image/')

class Admin:
pass

class Page(models.Model):
title = models.CharField(
maxlength = 100,
core = True,
db_index = True)
slug = models.SlugField(prepopulate_from = ('title',))
body = models.TextField(blank = True,
null = True)
sections = models.ManyToManyField(Section,
blank = True,
null = True)

parent = models.ForeignKey('self',
blank = True,
null = True)

order = models.PositiveSmallIntegerField(blank = True,
null = True)

related_pages = models.ManyToManyField('self',
blank = True,
null = True)

def __str__(self):
parents = ''
parent = self.parent
while parent:
parents = '%s :: %s' % (parent.title,
parents,)
parent = parent.parent
return '%s%s (%s)' % (parents,
self.title,
self.slug)

def get_absolute_url(self):
return '%s/' % (self.slug)

class Admin:
pass

> >>>>>> aportal-like page could be done using django.

[patrick k.]

did you take a look at the scripts I provided? it seems that this
might solve your problem.

another thing: my question was not about doing a CMS, it´s about
combining and displaying different types of content on portal-like
pages (which, of course, might be part of a CMS). and it´s also not
about "small company websites", but about bigger sites with lots of
different content-types and at least a couple of different editors.

when reading reviews about django - esp. when django is compared with
rails - it seems that django should suit these type of sites very
well. and, as I´ve mentioned before, there _are_ a couple of bigger
newspaper-sites out there. on the other hand, I haven´t seen a nice
solution for this so far. I´m just wondering how people actually do
these overview-sites (sorry, but I don´t have a better word for it ...).

thanks,
patrick