On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger <gre...@muellegger.de> wrote:
> I suggest reading this proposal online: https://gist.github.com/898375
> It's exactly the same as below but formated nicely.
>
>
> GSoC 2011 Proposal - Revised form rendering
> ============================================
>
> Hi my name is Gregor Müllegger. I'm a Computer Science student in Germany at
> the University of Augsburg currently in the fourth year of my studies. I first
> came to django shortly before 0.96 was released and a lots of awesomeness was
> introduced with the magic removal branch.
Hi Gregor,
Firstly, I'd like to echo Carl's sentiments -- this is a strong
proposal that shows you've researched the history of Django
discussions on this topic, and given it some thought of your own.
Carl has already raised several of the points that I noticed on my
read through. However, I do have some of my own queries.
Syntax
~~~~~~
You've proposed a syntax that goes something like:
{% form myform using layout "p" and fields "firstname" "lastname" %}
{% form fancyform.favourite_color using layout "p" %}
I have two questions about this syntax.
Firstly, while it looks fine for a small example, I can see how it
would rapidly deteriorate if you have lots of fields, or lots of
custom field requirements for each field. Django's template language
doesn't allow you to split tags over multiple lines, so what happens
when my tag runs over 80 characters (this simple example is already a
69 characters)?
Secondly, you appear to be using a single template tag for rendering
both forms *and* fields. Is there a motivation behind this?
Rendering modifiers
~~~~~~~~~~~~~~~~~~~~
I share Carl's concern about exactly how and why these are necessary;
even after your most recent post, I'm still not completely clear on
what they mean in practice.
On the one hand, I can see that there may be a use case for passing
arguments into the template rendering process. However, you seem to be
proposing a mechanism by which developers could define Python code
that alter widget rendering by performing such tasks as:
* selecting a different rendering directory
* changing the template that is used for a widget
* changing the layout scheme
* prepending/appending content onto a widget
I think I understand your motivation here, but my inclination is that
this will end up being a very complex system that won't end up being
useful in practice.
For example -- consider the case of validation. In an ideal world, it
would be nice to be able to just throw a switch and say "turn on
client side validation for this field", and then have that validation
work regardless of the rendering of the field itself. However, in
practice, it seems to me that the implementation of validation will be
tightly bound to the rendering of the field itself -- i.e, your widget
template would really need to be a "HTML4 text input with validation",
not a "text widget" with the HTML4 option and the validation option
enabled.
I can certainly see value in allowing template designers to pass in
keyword arguments when rendering fields on a template, allowing chrome
developers to define templates that implement various features (e.g.,
define a TextInput template that optionally has validation). However,
making this a complex registry and code solution seems like overkill
to me.
Form rows
~~~~~~~~~
If you look at the existing as_* form layout tools, there is a
distinction between gross form layout, and the layout of an individual
form row.
{{ form_header }}
{% for field in form %}
{{ pre_field }}}
{{ field }}
{{ post_field }}
{% endfor %}
{{ form_footer }}
Conceptually, the rendering for pre/post field could vary depending on
the field. How is this handled in your proposal? Is it part of the
form renderer? Or part of the widget rendering? This overlaps with
your discussion about error templates -- since errors (and their
rendering) is one of the major pre/post rendering activities for both
forms and fields.
CSS/Media
~~~~~~~~~
I'm not wild about the idea of having to include the same form content
twice in order to get CSS and JS included as where it is required.
I can see two options here.
Firstly, follow the lead of the {% cycle %} tag -- use the {% form %}
tag to define what the form will look like, but not actually render
where it is defined; assign the rendered properties to a context
variable, then reference that context variable when you want to
actually render something related to the form.
{% form myform <some content> as myform_rendered %}
{{ myform_rendered.media.css }}
{{ myform_rendered.media.js }}
{{ myform_rendered.html }}
This would be fairly easy to implement, but I'm not sure it would be
especially flexible.
Secondly, it may be possible to play a trick on the template compiler.
Jonas Obrist suggested this trick to me at Djangocon (US) last year;
however, I haven't had a chance to dig into it any more.
The trick goes something like this:
When you parse a template tag like an {% if %}, the template parser
scans forward until it reaches an {% endif %}. All the node content
that is discovered is then provided to the if node as the subtemplate
for the if.
However, there's no specific requirement that you need to parse until
you reach a specific tag -- you could just scan to the end of the
document, and treat the rest of the document as if it were the nested
content of an if that runs to the end of the page.
So -- you should be able to write a "CSS" template tag that reads to
the end of the template, and in the process, discovers all the {% form
%} nodes on the template. From that, you can determine all the CSS
requirements that your HTML document has.
It requires a bit of a twist in the document tree -- the entire
document effectively becomes a child of the CSS node in the template
-- but it should allow you to get access to form rendering
requirements before the form is actually rendered on the page.
Yours,
Russ Magee %-)
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
