[Catalyst] In HTML::FormHandler search form (no DB schema) -- how to populate a SELECT field via DBIx::Class?

Alexander Hartmaier alexander.hartmaier at t-systems.at
Thu Jan 20 10:20:30 GMT 2011

Why not solve it the exact same way?
Defined a schema attribute an pass your schema when constructing the
form object.
Maybe you only want to pass the country rs instead, whatever fits your
needs best.

Also note that HFH will automatically detect a belongs_to and populate
the Select without a need for the options_country sub!

Come to #formhandler if you have more questions.

Best regards, Alex

On Sun, 2011-01-16 at 16:41 +0100, will trillich wrote:
> Short version: If you have a HTML::FormHandler search form without a
> "has_field '+item_class'" (there's no data-base row corresponding to
> its contents) how to you reach your DBIx::Class schemas to populate a
> drop-down menu?
> Long version: This is in the context of a Catalyst app -- however, I
> do know this is either FormHandler question or a DBIC question, and
> not intrinsically a Catalyst question, but... hoping the wise folks
> here can nudge me in the right direction...
> We have several DBIC resultsets including Incident and Country. The
> Incident record has this relationship:
> __PACKAGE__->belongs_to( 'country' =>
> 'Incident::Schema::DB::Result::Country' );
> (And the country schema has_many incidents, of course)
> For the CRUD form related to the actual incident table, we have a
> matching HTML::FormHandler package with its
> has '+item_class'
> as expected. This makes it easy to create a
> sub options_country {
>   my $self = shift;
>   return unless $self->schema;
>   my $rs = $self->schema->resultset('Country');
>   #...
> }
> subroutine for the form, for populating a country drop-down menu in
> the HTML.
> But!
> For the SEARCH form, we are not interested in CRUD, plus we have extra
> fields (for example, we want the user to be able to bracket dates with
> a start-field and an end-field) so there's no one-to-one correlation
> with the database table -- meaning there's no "item_class" for the
> search form. And hence no schema to rely on.
> What we're looking for now -- unless there's a better more obvious
> paradigm -- is a way to get from an instance of the schema-object,
> back to the resultset, for searching.
> sub options_country {
>   my $self = shift; # note $c is not available here :(
>   # $self->schema will be UNDEF here
>   my $obj = Spill::Schema::DB::Result::Country->new; # Hard-wired,
> yes, is there a better way?
>   my $rs = $obj->???
>   # ?
> }
> I've looked at
> - $obj->result_source (Can't call method "resolve" on an undefined
> valued in DBIx/Class/Row)
> - $obj->result_source_instance->resultset (Can't call method
> "default_resultset_attributes" on an undef value in
> DBIx/Class/ResultSource)
> - $obj->result_source_instance->resultset_class->search({},{}) (Can't
> use string as a HASH ref in DBIx/Class/ResultSet)
> and a couple other dead ends.
> It's likely to be something obvious I've overlooked. :( Suggestions?
> --
> The first step towards getting somewhere is to decide that you are not
> going to stay where you are.  -- J.P.Morgan

T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.

More information about the Catalyst mailing list