Re: best practice for portal-like pages?
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 (whic
Re: best practice for portal-like pages?
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]>
Re: best practice for portal-like pages?
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 a
Re: best practice for portal-like pages?
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)
Re: best practice for portal-like pages?
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"
Re: best practice for portal-like pages?
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 mann
Re: best practice for portal-like pages?
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
-~--~~~~--~~--~--~---
Re: best practice for portal-like pages?
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
-~--~~~~--~~--~--~---
best practice for portal-like pages?
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
-~--~~~~--~~--~--~---
