[TurboGears] Re: Forms declarative style

[Don Hopkins]

Good question actually. It’s user friendly to group related elements together in the form (like x and y coordinates), and put important ones near the top (like title and description), so you need some way to control the order of dynamically generated form elements (and also a way to further customize each element).   Now that Ian’s invented a way to order the fields of an SQLObject, it’s possible to automatically generate forms to edit their fields in the same order they were specified by the database designer (or declared in the python class).   I want to be able to declare not only the order, but also other metadata about each field.   I made a database browser for OpenLaszlo based on SQLObject, but I resorted to awkward kludgery to order the fields with sequence numbers. http://www.donhopkins.com/drupal/node/44   Using an older version of SQLObject, I subclassed the various field and join classes so the constructors took an extra user defined “data” parameter that I could retrieve later. So I could hang a dictionary off of each field, to give it a sequence number to sort by, and store other presentation related information. I also had to subclass the various join fields so they had data parameters too.   The goal was to declare extra information about each field and join, like its sequence number, the name of a custom editor, user friendly label, help text, and other presentation parameters, so the server can automatically generate XML to drive a Laszlo user interface for browsing and editing the database, with custom widgets like checkboxes, image views, date pickers, map widgets, etc. (BTW: I can’t wait till Google Base drops the other shoe and publishes a web API!)   The new version of SQLObject now has a similar but undocumented feature that I don’t quite understand, with the _extra_vars Field instance variable, so I may be able to clean up my code and use that, instead of wrapping everything with my own subclasses.   Ian, how did you intend _extra_vars to be used: is it meant to hang user data off of fields, or am I subverting its true goal in life (remaining secret and behind the scenes in an undisclosed location)? The Join classes would also need to support _extra_vars as well. It would be great for dynamic user interface generation, if SQLObject supported an easy, documented way to attach metadata to fields and joins, and officially exposed the field order too, please!                 -Don     -----Original Message----- From: turbogears@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Grimmett Sent: Wednesday, November 16, 2005 8:40 PM To: turbogears@googlegroups.com Subject: [TurboGears] Re: Forms declarative style   On 11/16/05, Don Hopkins <[EMAIL PROTECTED]> wrote: The problem with the class based approach is that there's no way to reconstruct the order of the fields in the class, which is required for generating forms (of more than one field ;-). Since the fields are Beware of stupid question. Here it is. Why is it important to reconstruct the order of the fields? -- "Things fall apart. The Center cannot hold."                   - Life as a QA geek, in a nutshell. Best,     Jeff