On Mon, 6 Dec 2004 09:59:28 +0100, Marcus Ramberg wrote
> On 6. des. 2004, at 01.29, Simon Flack wrote:
>
> > On Mon, 6 Dec 2004 00:39:26 +0100, Marcus Ramberg wrote
> >> populate $r->objects from $r->{args}[0]
> >>
> >> For example, in my case, the the wiki I'm building, I could use this
> >> to set this to
> >> sub Mitiki::Page::populate_objects {
> >> my ($class,$r) = @_;
> >> my @obj = Mitiki::Page->search( node => $r->{args}->[0] );
> >> $r->objects([$obj[0]]);
> >> }
> >>
> >> (since I use a numeric id, not the node name, for pk but that's what
> >> I'll want to reference)
> >>
> >> Did that clear it up?
> >
> > Yes, but that's more or less what retrieve() is for:
> >
> > =head2 retrieve
> >
> > This turns an ID into an object of the appropriate class.
> >
> > Adding something so similar with a different name is a bit confusing.
> > Isn't
> > this just an example of a case where you need to define your own
> > Model::process
>
> Note that even tho retrieve exists in the maypole *documentation*,
> it's in fact not implemented by maypole at all, but by class::dbi,
> which documents it as follows:
I don't dispute that. But the purpose of Model::retrieve() in Maypole is
already defined and it's purpose is more or less what your requesting from
populate_objects.
> =head2 retrieve
>
> $obj = Class->retrieve( $id );
> $obj = Class->retrieve( %key_values );
>
> Given key values it will retrieve the object with that key from the
> database. For tables with a single column primary key a single
> parameter can be used, otherwise a hash of key-name key-value pairs
> must be given.
>
> my $cd = Music::CD->retrieve(1) or die "No such cd";
>
> Overriding this method to retrieve based on another column than the
> primary key is not a good idea, and would be a hell of a lot mor
> confusing.
>
> overriding process would end up in a lot of duplicated code, and is
> probably still a bad idea, as you suggested yesterday. thus, we
> should remove retrieve from the maypole documentation and add a
> method like populate_objects which is called with $r and calls
> retrieve in CDBI's case. Seeing as there are no finished alternative
> model implementations this minor api change should be of little or
> no consequence.
I don't know that. I thought that Simon had written an application with an
Email::Store model.
Here's another possibility. Define your own get_object_id() to translate the
name to an id:
sub Mitiki::Page::get_object_id {
my ($class,$r) = @_;
my @obj = Mitiki::Page->search( node => $r->{args}->[0] );
$r->objects([$obj[0]]);
return $obj[0]->id;
}
If I understand CDBI's memory cache correctly, because you store the object
temporarily, the subsequent retrieve() in process() shouldn't result in
another database hit.
But yes, we could deprecate retrieve() and replace it with populate_objects()
or similar. I'm just worrying about creating a sprawling API. Also, if you
accept that M::M::CDBI isn't going to cater directly for every concievable
CDBI model, then it makes sense to optimise it for the common cases. And I'm
not sure whether this is a common case.
--simonflk
_______________________________________________
maypole-dev mailing list
maypole-dev at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole-dev
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT