Quoting Peter Karman <[EMAIL PROTECTED]>: > Adam, > > Glad you are working on this too. Perhaps we can join forces. > Certainly. I've only really started using Rose about a month ago, so i'm not sure how much use i'll be, but you never know ;)
> 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 > In my initial screwing around with RDBO/RHTMLO i was doing that, and i still think it's probably the most appropriate place to stick Forms that are really tightly bound to columns (i'm thinking of a site administrator tweaking data in tables through a web interface) as opposed to something that might be used by actual users. The project I'm working on for example has a comments table, that has a bunch of information about the request (ip/ua etc) that created the comment stuffed into it. I wouldn't want to use the full form for the users for obvious reasons. For some reason, at the time i didn't think sticking that into My/Comments/UserForm.pm was as cool an idea as sticking it in My/Form/UserComments.pm. But i'm having second thoughts about it now. I'd never expect something like this to generate those other forms anyway though, i was just hoping to mimic the most commonly used tactic people using RDBO and RHTMLO together are using (and i have no idea what it is) > 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 understand the attraction of using yaml to expose pieces of the form, i'm just not sure how you'd really go about implementing it. I'm also not sure i'd ever use these forms for a public facing app either (because i tend to have created/modified timestamps in tables that no one ever wants to see but me.) I also don't work in an environment where anyone other than me would be controlling the display, so editing a yml file doesn't feel a whole let different (to me) than editing the .pm. If i was leaving that work to designers though, i could totally appreciate the distinction. > 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. this makes sense to me. > > 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? I agree with everything John posted with regards to this. But is also agree with Cees that the parse_value functions and error handling should be cleaned up to and made consistent across the ::Column classes (assuming this hasn't already happened, that post is from July). > Adam, if you're interested in working on this together, we can take > it offlist and hash out a course of action. sounds like a plan. Adam ------------------------------------------------------------------------- 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
