FAQ
*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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110116/e42c622f/attachment.htm

Search Discussions

  • Alexander Hartmaier at Jan 20, 2011 at 10:20 am
    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.
    *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
  • David Schmidt at Jan 21, 2011 at 7:40 am

    On Thu, Jan 20, 2011 at 11:20 AM, Alexander Hartmaier wrote:
    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.
    *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    I agree with Alexander,

    this cookbook section should be helpful

    http://search.cpan.org/~gshank/HTML-FormHandler-0.32005/lib/HTML/FormHandler/Manual/Cookbook.pod#Server-provided_dynamic_value_for_field

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJan 16, '11 at 3:41p
activeJan 21, '11 at 7:40a
posts3
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase