You can also check: http://trac.turbogears.org/turbogears/wiki/FormValidationWithWidgets http://trac.turbogears.org/turbogears/wiki/FormValidationWithWidgetsTwo
and a tutorial at http://trac.turbogears.org/turbogears/wiki/SimpleWidgetForm for more info On Mar 11, 2006, at 8:17 PM, Alberto Valverde wrote: > > > On Mar 11, 2006, at 7:12 PM, Robin Haswell wrote: > >> >> Thanks, you've been really helpful. Can I ask a couple of quick >> questions about this? I'll even stick up a trac section on my >> experience >> for a bit of extra docs in return :-) > > That would be great :) >> >> I'm a semmantic stickler - what would you recommend is the best >> way to >> organise this lot in to fieldsets? I put everything apart from submit >> buttons in to fieldsets - provides context. I looked at the FieldSet >> class, the best I can come up with goes something like this: >> >> class AccountFields(widgets.WidgetsDeclaration): >> userId = widgets.TextField() >> password = widgets.PasswordField() >> emailAddress = widgets.TextField() >> >> class PersonalFields(widgets.WidgetsDeclaration): >> displayName = widgets.TextField() >> firstname = widgets.TextField() >> lastname = widgets.TextField() >> >> class RegisterForm(widgets.WidgetsDeclaration): >> account = widgets.FieldSet(legend="Account Information", >> fields=AccountFields()) >> personal = widgets.FieldSet(legend="Personal Information", >> fields=PersonalFields()) >> >> etc... return dict(form=widgets.TableForm(fields=RegisterForm(), >> submit_text="Register")) >> >> Does that look alright to you? > > > I do something similar myself, you've seemed to "get" it... :) > > Remember though that your'e using nested widgets, this means your > controller should do something like: > > def controllermethod(self, account, personal): > do_something_with(account['userId']) #account is a dict, so is > personal > etc... > > When using nested Compound widgets (Form, Fieldset, etc...) field > names are automatically encoded on display (you can check your > rendered source) so they can be decoded back when the form is > submitted and get a nested structure back (this is done internally by > FormEncode's NestedVariables decoder) > > A bit of FormEncode studying is a must if you want to take all the > potential of this. Ideally, all validation should be done by using > the built in FE validators or by subclassing your own. This "cleans- > up" your controllers and let's use reuse validators easily in > different forms. > > You can do lot's of real nifty stuff whe you define your schemas with > pre validators, chained validators, etc... For example, the typical > "password, repeat password" with a FieldsMatch chained_validator in a > Schema. All this is best explained at FormEncode's docs. > > However, a word of warning, some cleanup/refactoring is going on in > the trunk regarding this and the widget API *might* change a little > inside compound widget templates (the semantics will be the same). > Not much, but some new convencience functions to have more control of > the fields layout when you're designing your templates (you can take > a peek at the FieldSet template here: http://trac.turbogears.org/ > turbogears/browser/trunk/turbogears/widgets/forms.py#L470 and compare > to the current template here http://trac.turbogears.org/turbogears/ > browser/tags/0.9a1/turbogears/widgets/forms.py#L448) > > Alberto > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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 -~----------~----~----~----~------~----~------~--~---
