Hi guys,
As I said, while working on the display_field_for support I've found
some problems to support
a full_qualified_form and come to the conclusion that such a form can
be really confusing for our users (it's already confusing me) and
provides us with nothing.
Background: the main idea to support this type of form was the ability
to display more than one form in a page without the problem of errors
being displayed in both forms if they have fields with the same name.
Anyway this is a wrong use case, if you are displaying two forms on the
same page there is no problem but once the user submits one of the two
you should redisplay (in case of errors) only the submitted one,
moreover we don't need full qualification of a form since for the web
nature we can validate only one form at once not two or more (thanks
god ;-)).
Without discussing too much further, this is a list of some (there are
others for sure that ATM don't come to mind) of the problems and
inconsistency we will experience thanks to this devil form:
- if you use a fully qualified form (fqf from now on) your method
signature should become save(self, form_name) and not save(self,
[form_fields]), someone will ask why, it looks bad and moreover if we
would like to make it work in the other (standard) way we will need
some really bad hacks to adapt input_values (I've already tried)
- if you want to prepare a fqf you need to pass a nested dict like this
one dict(form_name=dict(...)) and not dict(...), this is inconsistent
with how you populate any other CompoundWidget and to support it we
need another bad hack, finally passing a options dict to a fqf will be
different than assigning a value to a fqf
- if I use a fqf should I use display_field_for("form.age") or
display_field_for("age")? why? and why inside a widget template I use
only the latter? there is even the possibility (if we don't put an hack
in) of having both methods working in the same way and that can be
confusing (more than one way of doing it)
- Alberto needed another hack (sorry, my fault) to support it on the
schema generation, that's another sign that this is plain wrong
So my conclusion:
- remove fqf as it's really unneeded (and used by no one ATM luckily),
forces use to use some bad hacks, introduces inconsistency in our
widget framework and will cause more problems than benefits (no one),
moreover it encourages our users to adopt some bad practices
- just add a form attribute to the Form and use it only to prepare
fully qualified ids for our fields (that's a nice thing for namespacing
ids)
- implement display_field_for, value_for, error_for, options_for in a
sane way that's *impossible* if we need to support a fqf
Opinions? I can prepare a final patch fairly quickly, it's almost ready
and things are looking pretty nice there.
Ciao
Michele
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~----------~----~----~----~------~----~------~--~---
