Thanks Robert!
The @inclusion_tag decorator is really nice! Much nicer than what I
wrote above.
One thing I'm not too keen on with @inclusion_tag is that the template
is hard coded in the tag itself. (Did I understand that correctly?)
That means everytime I want to use a different template, even if the
logic for populating the context is the same, I need to write a new
tag. It would be nice if it were possible (optionally) to pass a
template name as a parameter to an inclusion_tag.
Looking at the code for inclusion_tag() it doesnt look that hard to
optionally pass in a template name in the same way you can optionally
pass in a context - i.e. make file_name an optional parameter and add
takes_template as an optional parameter defaulting to False. If
takes_template were set to True the function should take a template
file name as its first parameter (or second if takes_context is also
True).
If nobody objects (rather, if people think it's a good idea), I may try
to submit a patch for this.
Thanks.
Robert Wittams wrote:
> Colin Howlett wrote:
> > Robert Wittams wrote:
> >
> >>Sorry, I just can not work out what on earth you are actually trying to
> >>achieve - too many instances of the word 'generic'... A concrete
> >>example would be best.
> >
> >
> > Robert,
> >
> > Sorry, I guess I wasn't communicating very clearly.
> >
> > What I want is something like the {% include %} tag but with batteries
> > included. With the {% include %} tag I still have to find some context
> > from somewhere to render the included template - either it's provided
> > by the main (custom) view or by custom template tags - I'd like to get
> > it from something like a generic view - the less coding the better.
> >
> > An example:
> >
> > Suppose I make a very simple site to show details of people - I have a
> > template to show name, date of birth etc. I want to visit e.g.
> > http://localhost/people/1/ to see the first person's details,
> > .../people/2/ to see the second etc., so I create a urlconf to connect
> > urls of the form /people/(\d+)/ to an object_detail generic view and
> > pass in a dictionary with app_label and module_name set appropriately.
> >
> > Suppose I make a very similar simple site for cars instead of people.
> >
> > So every page looks something like this in my people app:
> >
> > Name: Bob Jones
> > Date of birth: 10/10/2010
> >
> > or this in my car app:
> >
> > Manufacturer: Ford
> > Model: Focus
> > Color: Red
> >
> > Then I decide I would like to add, on each page, next to the detail of
> > each person or car, a list of all people or all cars, so I can click on
> > a person or car and it will take me to the detail page for that person
> > or car (which still has the list next to the detail). So every page
> > looks something like this in my people app:
> >
> > Bob Name: Bob Jones
> > Mary Date of birth: 10/10/2010
> > John
> >
> > or this in my car app:
> >
> > Ford Focus Manufacturer: Ford
> > Hummer H2 Model: Focus
> > Fiat Panda Color: Red
> >
> > If I was to make a list of all cars or people as a separate page I
> > could use an object_list generic view, but since I've already used an
> > object_detail generic view for my page I can't use another view - each
> > page has only one view. Obviously I could write a custom view, but I
> > like generic views - what would be nice would be if I could make a page
> > just for the list, using a generic view, configured with a url, and
> > then include that page, rendered by its generic view, into my original
> > page, just by including its url. That's what my template tag above
> > does.
> >
> > In other words my {% include_url %} template tag is kind of like the {%
> > include %} tag, but it doesn't take the path to a template, it takes
> > the url of a page, and instead of being replaced by that un-rendered
> > template (which is subsequently rendered with the context of the
> > template it is included within), it is replaced by the rendered page.
> >
> > --
> >
> > An alternative would be to write template tags equivalent to each
> > generic view and use those along with an {% include %} tag.
> >
> > --
> >
> > I think each solution has their pros and cons - my include_url tag
> > requires that the pagelets (i.e. the pages showing just the lists) have
> > their own urls - which doesn't seem right since nobody should ever
> > really navigate to those urls (except perhaps for testing) - they're
> > just used for including in the main page.
> >
> > On the other hand if I use some kind of new 'generic' template tags
> > (i.e. template tag equivalents of generic views) then I have two
> > choices:
> >
> > - I could add the 'generic' template tag to the *included* template -
> > but then the included template has to hard code all the values to pass
> > to the 'generic' template tag (such as the app_label and the
> > module_name) and I can't re-use it.
> >
> > - I could add the 'generic' template tag to the *including* template,
> > but then it pollutes the context. The generic template tag would have
> > to return something like 'object' or 'object_list' so I couldn't add
> > two in the same template.
> >
> > I'm still not sure which is the best way, or if there's another way I
> > haven't thought of.
> >
> > I hope that's at least slightly clearer.
> >
> >
> Ok,
>
> I think you want to use inclusion_tag.
>
> It is an easy way to create an template tag with custom logic.
>
> Search back in the archives for examples of its use, or look at the
> examples in the admin templatetags directories.
