On 10/22/2007 11:29 PM, [EMAIL PROTECTED] wrote: > I've been fooling around with this idea for the last couple of days > and I was wondering if I could get some feedback from the list.
Adam, Glad you are working on this too. Perhaps we can join forces. I started something similar here: http://www.msi.umn.edu/~pek/Garden.txt Slightly different conventions. Rose::DBx::Garden puts a Form.pm class in next to the RDBO class, so you'd get something like: lib/My/Thing.pm lib/My/Thing/Form.pm That's so if you had a Manager class, you'd have them together like: lib/My/Thing.pm lib/My/Thing/Form.pm lib/My/Thing/Manager.pm 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. You'll also see in there some code wrt schemas. I found it useful to make my class structure more closely reflect the namespace structure of my schemas (since I use psgl), but the same could be true for mysql. The idea is that there's one primary RDBO subclass, which each schema/db class subclasses, and then each table class subclasses the schema/db class. The advantages I have found are that I can apply methods to all databases/schemas by putting them in my main subclass, or per-db/schema by putting them in my schema class. For example: lib/My/RDBO.pm lib/My/SchemaA/Table1.pm lib/My/SchemaA/Table1/Form.pm lib/My/SchemaA/Table2.pm lib/My/SchemaA/Table2/Form.pm lib/My/SchemaB/Table3.pm ...etc I do this because I have several projects that I want to use the same My::RDBO code, but I want to customize behaviour at the schema/db level as well. It also lets me set the schema() value for all the associated tables in one place, since the standard make_classes() code does not appear to generate that piece. The other thing I haven't yet got to (but was hoping to work on today) is some ways to tie the validation pieces of RHTML and RDBO together so that the validation code can be defined in one place. As Cees noted earlier in this same thread, the default validation code in RDBO is actually less stringent than the equivalent in RHTMLO, and so right now I am leaning towards a way to make my RDBO classes call the RHTML::Form::Field validator() code. Any thoughts about this? Adam, if you're interested in working on this together, we can take it offlist and hash out a course of action. cheers, pek -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ------------------------------------------------------------------------- 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
