On Sep 15, 8:50 am, "Eduardo O. Padoan" <[EMAIL PROTECTED]>
wrote:
> On Mon, Sep 15, 2008 at 9:39 AM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> > That's a good point. Mixing {% include %} and {% with %} is both more
> > verbose and less flexible than if using a custom tag. In this case,
> > using a custom filter would also make sense since it's about
> > presentation:
>
> > {{ form|render_form:"thisway" }}
>
> I tend to see filters more as a way to format text, and inclusion_tags
> looks more like function calls:
>
> {% show_fields comment_form %}I've long been of the opinion that this is the way to go for form rendering. The problem is that it's not easy to tell the inclusion tag to use a different template, for those who want to customize. And as Simon points out, it's not immediately obvious where the actually HTML is pulled from. However: - Any template can be globally overridden - all you need to know is the name - Ticket 9093[1] will greatly improve this situation Since I was doing it this way for a large project, I already had the code written, so I cleaned it up and released it as django- renderform[2]. I think this approach has a much more appealing future than as_p, as_ul, as_table and such, especially if #9093 makes it in. [1]: http://code.djangoproject.com/ticket/9093 [2]: http://code.google.com/p/django-renderform/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
