Peter Karman wrote: > > On 10/23/2007 11:29 AM, Bill Moseley wrote: > >>> lib/My/Thing.pm >>> lib/My/Thing/Form.pm >> Is that one form for each table kind of mapping? >> >> I might have multiple forms for each table (or groups to tables) and >> they are more related to the specific request (update user profile vs. >> update user via admin interface) that to the table. Validation >> requirements might be different for the same field on different forms. >> > > Yes, I expect that real-world scenarios will demand that a single Form > actually > interacts with multiple tables via a single RDBO object, and/or multiple Forms > might end up representing the same table(s). That's ok. This project is just > to > bootstrap some same defaults based on a 1 table = 1 form formula. Kind of like > Rose on Rails. ;) > > Think of it basically like adding a make_forms() method to the RDBO Loader. > >> So my form module names tend to be based on the request name. So in >> Catalyst, for example, my forms are basically found in >> $App/Form/<Controller>/<Action>.pm Makes it easy to auto-load the >> forms for any given action. > > Cool idea. > >>> But of course, I can see the advantage of a totally different namespace for >>> Form classes. I have been trying to go down the route of using a .yml file >>> to >>> define the basic Form class, and to make that available to non-programmers >>> to >>> edit, especially for labels, etc. That way I don't have to go in and modify >>> a >>> .pm file every time marketing changes their minds about what they want a >>> customer to see. But exposing just the labels is about all I think I want to >>> do, and it might end up being more work to go the .yml route. I haven't >>> made up >>> my mind yet. >> I keep the labels in the html templates. I started using YAML files >> to define the fields and labels, but then I ended up with more places >> to define things than I felt was reasonable. >> > > Yes, that (labels in HTML) is what I do currently as well. I'm inching closer > to letting go of the 'labels with yaml' idea. >
Just a bystander, but I'd like to interject a few things.
First, make it easy to localize text...be it message, or field labels
and buttons via callback. Sometimes, $catalyst->localize needs to do the
localization, sometimes it's MyApp->maketext. Localization either seems
to always be last on the list, or attempted to be handled [incompletely]
by the various form managers out there.
As far as defining the form class in yaml, it's good, but imho make sure
it can define EVERYTHING about the form, not just the fields, but the
constraints, messages, etc. When I started working on Mango, I soon
became frustrated that I had to do the form format in one place...and
the validation profile in another...and the message in another...esp
when mixing CGI::FormBuider, FormValidator::Simple, etc, so I ended
marrying them all into one:
> ---
> name: form_name
> method: POST
> javascript: 0
> stylesheet: 1
> sticky: 1
> submit: LABEL_CREATE
> fields:
> - sku:
> type: text
> size: 25
> label: LABEL_SKU
> maxlength: 25
> constraints:
> - NOT_BLANK
> - LENGTH, 1, 25
> - UNIQUE
> messages:
NOT_BLANK: 'sku cannot be blank'
Things like LABEL_CREATE get sent through Maketext to get localized...or
they can just be the actuall text itself, etc.
-=Chris
--
Let them eat cake and false positives.
-----BEGIN NSATT SNOOP BLOCK-----
building bomb tower terrorist grenade c4 explosive plot hijack
plane police feds white house guns dirty device convoy president
war chemical death drop off mule undercover launch rocket drug
covert cell cerin mass infidel Allah package subway mass
------END NSATT SNOOP BLOCK------
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
