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
On 7 Haziran, 10:39, "patrick k." <[EMAIL PROTECTED]> wrote:
> 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
> >>>>>> aportal-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
-~----------~----~----~----~------~----~------~--~---
