Hi Chris,
2011/6/27 Chris Beaven <smileych...@gmail.com>:
> How do I override a field's label or help text?
> Specifically, help text may need to look something like: [[Can this person
> <a href="{% url help-managers %}" title="What's a manager?">manage</a> {{
> site.name }}?]]
This isn't addressed with the proposed template tags. You can still write out
a single row by hand if you need to tweak it in the low level details. I know
this is not ideal and exactly what we want to avoid with the new rendering.
Because of this I will try to design the code that spits out the form in the
end to be very modular. Basically it should be possible in the end to have
your own "formconfig" template tags that change the rendering a bit, like
changing a label or the help text (label is also my sample usecase).
However I think these templatetags could go into a thirdparty app. First
reason is to show-case that thirdparty rendering modifications are possible,
second to not clutter the builtin tags with too many possibilities. I would
like more to provide a framework for rendering, than all the tiny details you
propably could plugin into it your self.
BTW: even without the thirdparty apps it's already possible to change the
label for a field in an (somehow) easy way. Just extend from the row template
you use for your other rows in the form and override the {% block label %}.
Another option is to have something like this in your row template:
{% firstof label field.label %}
label is usually not in the row's scope so field.label is choosen. Now you can
modify the label with:
{% formrow myform.field with label="My new label" %}
> How are HTML classes specified for rows which are required / contain errors?
> (and one more slightly obscure one, probably out of scope...)
This can be achieved in the row template:
<div{% if field.errors %} class="errors"{% endif %}>
> How does a row know whether it contains HTML block elements?
> For example, a "p" row needs to render differently if it contains HTML block
> elements, such as a field represented as an unordered list of checkboxes.
This is not addressed, and I have no clue how we should do this -- or if we
should do this at all :o)
2011/6/27 Chris Beaven <smileych...@gmail.com>:
> Oh, and one more critical one:
> How does the form in python have knowledge of the widget which the field was
> rendered with as picked by the template?
> This is critical since building the form's data requires using the widget's
> value_from_datadict.
I think thats conceptually not possible. We simply can change the widget during
template rendering time, which makes it impossible to decide in the python
code with which widget we end up. And theoretically we could even render the
form twice with different widgets. Or throw the rendered template away without
using the widget at all.
So I think we must make clear that the used widgets must be somehow
compatible. I agree that we need to document this in one or the other way.
--
Servus,
Gregor Müllegger
--
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.
