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
Am 07.06.2007 um 15:16 schrieb 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
>
>
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
