unique text description for rows in multi-column-keyed tables
mackler
I'm looking at two methods in two modules:
in Rose/HTMLx/Form/Related/RDBO/Metadata.pm:
show_related_field_using()
in Rose/DBx/Object/MoreHelpers.pm:
unique_value()
It looks to me as if there might be some duplication of code here. I
noticed this since the output from each appears in a least one place,
and in those at-least-two places it seems reasonable to expect a user
to want consistent output in all of those places.
Specifically, Rose::HTMLx::Form::__set_menu_options uses
show_related_field_using to get the text to display in a form's
pulldown menus where the choices represent rows in a related table.
On the other hand, the edit.tt template from the YUI uses
unique_value() to choose text to display as a label for the row/object
being currently edited. My guess is that the output of unique_value
gets used elsewhere as well.
Maybe I'm missing something, so first let me ask you this: is there a
suggested optimal way to display a text label for a row of a table
that does not have a text-based, single-column, unique key? (For
example if first_name and last_name each have their own column and I
want the row label to contain both names?)
The first solution I came up with was to copy the init_metadata method
out of the base Form.pm that Garden made for me, and to override it in
the specific Form.pm file for the class that has the pulldown menu. I
then added one line to the method setting related_field_map for that
specific class, so the whole overriding method looked like:
sub init_metadata {
my $self = shift;
return $self->metadata_class->new(
form => $self,
controller_prefix => 'RDGC',
related_field_map => { 'user_id' => 'full_name' },
);
}
The first problem with this solution is that it's going to get wiped
out next time I plant() the garden, and since I'm still creating the
database, I re-plant it every few hours to make sure everything is
still
working.
The second problem with this is that this is in the class making the
menu, not in the class referred to by the menu. While this change
fixed my pulldown menus, as mentioned above the unique_value method is
not affected by this related_field_map.
So before I do too much coding, it's probably worth my asking you if
there exists a good way to make one change that will turn all my
displayed, integer, surrogate primary key values into displayed,
natural keys, including values from multiple key-columns as necessary?
If the answer to that question is no, then my next thought is that
perhaps the show_related_field_using and unique_value should be
combined somehow for consistency? Perhaps show_related_field_using
could itself call unique_value so that changing the latter will fix
the former? I'm interested in your thoughts on this as it is the
issue immediately confronting my development. Thanks very much.
Adam Mackler
Peter Karman
different address.