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
-~----------~----~----~----~------~----~------~--~---
