On 21/04/2006, at 8:19, jvanasco wrote:
>
> I've been trying to reverse engineer widgets/forms.py for about 7
> hours
> now , using the wiki samples as a starting point . i kind of expected
> having something up and running
>
> your sample is a godsend for this alone:
>
> email = TextField(validator=Email(not_empty=True))
>
> i've been going crazy tyring to set up a way to do a chained_validator
> on Email . i never saw taht option in validators.py or FormEncode.
Chained validators can only be placed in a Schema, which in turn can
only be placed in a CompoundWidget (like the FieldsSet or Form are).
The point is that for chained validation to work, you need to operate
on a dict of values. Normal widgets expect a string as input,
compounds expect a dict.
class MySchema(Schema):
chained_validators = [...]
>
> i think i'm going to try and make an abstracted form class though -
> i'm
> really partial to the approach of having a class that calls all the
> widgets (if thats what you want ) or the access the args ( if thats
> what you want ) and can create an appropriate output ( perhaps for tal
> instead of kid ). aside from being able to switch outputs at the user
> level, an approach like that *should* be able to help compensate for
> API changes ( like how the .8x doesn't work with .9x etc )
I'm not sure I understand what you mean here so I'll try to guess...
If you want to hack on TG's widgets template engine support (the
easiest way IMO to customize the kind of output widget's produce)
you'd be interested in load_kid_template in meta.py. What would be
ideal is a template engine for widgets, which took strings like
"cheetah:templates.tpl" like expose decorator does and applies the
correct template engine for the output. However, different template
engines for widgets are not a priority right now (you're the first
one AFAIK that has suggested this).
However, make sure you investigate first because you might end up
reinventing the wheel. The class you're describing (one that calls
the widgets and gives them their args) is exactly what a
FormFieldsContainer does.
The widget API is new to .9 so I don't see how you want to compensate
for API changes there :)
>
> anyways, thanks a ton for that explanation - you should add that to
> the
> wiki.
>
You're welcome :) Regarding the wiki, It'l be best for the example to
land somewhere in the documentation that's going to be produced on
29th. The Trac's wiki is only causing troubles like the one you
faced: Doc's get stale pretty fast when the development pace is high,
and there's some mysterious way that outdated information finds to
hide in there and come biting a couple of months later :)
Luckily some work is being done in that direction with Docudo, which
aims to be a collaborative documentation built with TG which supports
revisions and tagging so it's clear at what version of the software
the docs are targeted at. More info at Ronald's blog: http://
tinyurl.com/nozan
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
-~----------~----~----~----~------~----~------~--~---
