On 10/17/05 8:06 AM, Aaron Ross wrote:
>> sub relationships_by_column
>> {
>>   my($self, $col_name) = @_;
>> 
>>   my @rels;
>> 
>>   foreach my $rel ($self->relationships)
>>   {
>>     next  unless($rel->can('column_map');
> 
> Does this mean that not all relationships define a column_map? What
> would a relationship without a column map do?

Hey, you never know.  Nowhere is it written that every relationship will
always have a column_map() method.

>>     my $col_map = $rel->column_map or next;
> 
> Does this mean that not all relationships with a column_map method
> return a column map?

It might not be defined yet.

> IMHO, it would be nice if th API didn't require checking the return value.

I'd rather not have column_map() return an empty hashref because that
implies that "the column map for this relationship contains no columns"
rather than "the column map for this relationship has yet to be specified."
In your code, if you're sure it'll always be defined, then feel free to skip
the error checking.  In an actual RDBO method, I'd like to either do the
check or throw an exception in the case of an undefined column map.

>> But my question is, what are you doing that has to differ between columns
>> that are included as part of a relationship column map and those that
>> aren't?  IOW, what are "do one thing" and "do another thing" in your
>> example?
> 
> Generating HTML forms, of course!

Ah, I see where you're going with this.  I suggest making your own subclass
of RDBO and adding methods like relationships_by_column() as necessary.
Then when you've got something useful up and running, send me a patch
containing all the methods that you added that you actually ended up using
:)  Then I may tweak them a bit but I will probably add them all.  It's just
that I'm hesitant to add methods until someone actually using them (i.e.,
you) has confirmed that they're useful.

> Really, I'm porting AsForm and FromCGI from Class::DBI. Does something
> similar already exist? I see Rose::HTML::Objects and Rose::DB::Object
> which implies some things, but I don't see the equivalent of
> Rose::DB::Object::AsForm.

Yeah, there's no automatic "make a form from this RDBO" module, mostly
because there are so many different choices that could be made in that
process.  You can take a look at the build_form() method this module in CVS
to see an example of building a RHTMLO form from an RDBO:

Module:

    Rose::WebApp::Example::CRUD::Form::Edit::Auto

CVS (instructions: http://sourceforge.net/cvs/?group_id=147570)

/rose/modules/Rose-WebApp/lib/Rose/WebApp/Example/CRUD/Form/Edit/Auto.pm

Web view:

http://cvs.sourceforge.net/viewcvs.py/rose/rose/modules/Rose-WebApp/lib/Rose
/WebApp/Example/CRUD/Form/Edit/Auto.pm?view=markup

This is all "in progress" code so take it with a grain of salt, of course.
Also, it doesn't handle related objects at all.  If it did, I'd probably
need to make methods like relationships_by_column().  But since you're
actually doing it, I'll let you tell me what you need :)

My advice is to add support for one relationship type at a time.  Start with
an easy one like "one to one" and actually check for $rel->type eq "one to
one" (rather than $rel->isa(...)).  It shouldn't be too bad. But if you want
to make it really generic, remember that you'll have to handle objects with
multi-column primary keys and multi-column relationships :)

-John




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object

Reply via email to