Hi Michele, Nice! I've fixed pre_bind_params at r954 because it wasn't working as expected, something had changed between your prev display_field_for and the one in the patch I sent you but dunno what. Anyway, now it's fixed (though it's specialized in prebinding to display_field_for and render_field_for exclusively...)
I've uploaded a sample project taking advantage of this new features at: http://www.turbogears.org:7779/turbogears/attachment/wiki/ SimpleWidgetForm/forms_tut.tar.2.gz So they can be seen in action. Some notes: CSS sucks, only displays right in Firefox (I'm no css expert so feel free to improve) Works as of r954 I might turn it into a full fledged tutorial once this has stabilized more. Regards, Alberto On 15/03/2006, at 14:11, Michele Cella wrote: > > Finally with r950 display_field_for and render_field_for is in. > > http://www.turbogears.org:7779/turbogears/changeset/950 > > Just two comments, I have integrated a patch Alberto sent to me > yesterday that provides in any FormFieldsContainer a ready to use > display_field_for/render_field_for that doesn't require any other > parameter apart the name (curried), to do this we are using the > pre_bind_args function, I added a comment we already have bind_args in > util.py can this work Simon? (hope you're reading this). > > And again regarding this, the patch sent to me by Alberto was using > that function even inside our Form or FieldSet templates, so we had > something like: > > display_field_for(field) > > instead of: > > field.display(value_for(field), **options_for(field)) > > while this is more verbose I haven't used the solution proposed by > Alberto for two reasons: > > 1) display_field_for(field) looks silly and a no sense, we are asking > it to display the field for "field" O_o, display field for is supposed > to just work on a name basis, that means you already know the field > name and you use it to retrieve the displayed field, our form are more > generic and shouldn't make an assumption on the field name, also > value_for and options are more explicit and show are you're > supposed to > work with widgets > > 2) yet another change to our templates, backward compatible but people > may want to update > > Anyway I do think we should show how you can use display_field_for in > this way, but not in a generic container widget but for example in a > nice IdentityLoginForm, for example this looks pretty good: > > template =""" > <form> > <label>Username</label><p > py:content="display_field_for('username')"></p> > <label>Username</label><p > py:content="display_field_for('password')"></p> > <input type="submit" /> > </form> > """ > > that's just an example, here it makes more sense IMHO. > > Opinions? > > Ciao > Michele > > Michele Cella wrote: >> >> Just seen this message (ggroups sucks lately). :-( >> >> Anyway done at revision 945 >> >> That's the commit message: >> >> Backward compatible cleanup: >> - Removed full_qualified_form >> - Prepare the ground to support display_field_for (coming soon) >> - Support for required fields in a Form (adds a css class >> automatically) >> - Support for more than one form in the same page >> >> Hope it's all good, I've stress tested it but it's never enough. >> >> display_field_for is ready but will come tomorrow (here), now I'm too >> tired. ;-) >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
