On 14/03/2006, at 13:52, Michele Cella wrote:
>
> 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.
>
+100 :) It also complicates validation code...
> 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
Yep, agree...
One thing just in case I'm missing something... Are you planning to
introduce the "fieldset.field" syntax at display_field_for?? If true,
I don't think it's a good idea:
If you put in a form's template display_field_for("fieldset.age"),
who wraps the field in the <fieldset></fieldset> tags??
Maybe you already thought about this but just in case...
>
> 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.
fqf bye bye.... (No one displaying two forms in the same page, right??)
Please take a look at the patch I've sent you... (sorry people, Trac
is down :( )
Alberto
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
