On 21/04/2006, at 5:19, jvanasco wrote: > > first, a question: > > i'm trying to use forms via the widgets and continually running into > issues > > the latest of which- i have some form fields that are required - is > there any way to get a red asterisk ala '<span > class="required-input">*</span>' into the label, or is am I SOL ? > > then a critique: > > i really intensely dislike the forms support in turbogears. > > the widgetless approach ( > http://trac.turbogears.org/turbogears/wiki/WidgetlessForm ) seems > to be > the most straightforward, but no different than CGI and has no > validation > > the simple widget ( > http://trac.turbogears.org/turbogears/wiki/SimpleWidgetForm ) is less > straightforward , and doesn't seem to offer anything over dynamic html > generation - which can be awkward to fit into a design layout > > then there's the formencode approach ( > http://trac.turbogears.org/turbogears/wiki/ > FormValidationWithWidgetsTwo > ) which is just a headache. i'm staring at a class FormTest > controller, a def to create a form, and then a seperate class to > validate the form. thats just too much - its confusing and awkward. >
You're absolutely right, docs pretty much suck ATM. That will be
fixed on 29th for sure...
> i've spent the better part of the night trying to hack out something
> modeled similar to a TAL form generator i once made based on Perl's
> formbuilder ( www.formbuilder.org ) , but with no luck - perhaps
> someone here can offer me some pointers
>
> Here's the general idea that I have so far:
>
> every 'form' is instantiated as a class of fields /validators
> /descriptors and an output provider is specified
>
> someone can just make an inheritable form class, and if the widgets
> behind it change - not to worry - the parent class handles it all. no
> one even needs to use the widgets - it can output into non-widget
> dicts
>
> it still uses everything that TG uses right now, but behind the scenes
> (ie, the parent class handles widgets and FormEncode, etc )
>
> it would look something like this:
>
> Class Form__formname(tg_form):
> fields = { 'name' : { 'type':'textfield' , 'validators' :
> 'NotEmpty' }} # where fields is a dict of dicts. keys are the
> fieldname, internal kv pairs are semantic descriptors
> chained_validators = {}
> output = 'widget'
>
> inherited class functions
> def validate(self):
> runs through the fields using tg validate on each field based
> on the descriptor
>
> def render(self):
> if output is 'widget' does a widgets.TableForm
> else handles errors, plain text
>
> maybe TG can handle something like that already? i don't know. right
> now though, forms are overly complex and quite a turnoff for me. i
> can
> see the seeds of some powerful form creation/validation in TG, but its
> kind of crazy that there's no Form class - just tons of stuff for form
> elements. i'm picky - i like all my forms in their own namespace and
> everything nice and compartmentalized. if TG can support this
> already,
> I'd love to know how. otherwise i'm going to have to port perl
> code to
> python -- and nobody here wants me to do that.
>
Well, maybe you should compensate the current lack of docs and
investigate a bit, you know, the UTSL way. It's really worth it...
you might also learn to appreciate other people's hard work you're
lucky to get for free.
I'm attaching a simple but not trivial form example in a quickstarted
project in the hope it will be helpful to you and anyone else stuck
at the widgets...
If you have any other questions feel free to ask :)
HTH,
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
-~----------~----~----~----~------~----~------~--~---
sampleform.tar.bz2
Description: Binary data
