Rendering a might_have relationship/field

[will trillich]

Short version: table "incident" might_have an instance of table "incident_info" which has incident_info.id that refers to incident.id, and incident_info.info, a text-blob field. What code is required to render the related info.info field as an optional field in the incident edit-screen?

Long version:

Getting a related incident_info record once I have an incident record is a snap:

$incident->$field; # any field from incident record

$incident->info->info; # the info text field from the related incident_info.info field

From http://search.cpan.org/~gshank/HTML-FormHandler-0.40007/lib/HTML/FormHandler/Field.pm it's straightforward to get FormHandler to render simple fields from the current item_class ($incident in the above example). 

But how do we get FormHandler to render the html and read and write the related table properly? ($incident->info->info in the above example)

########################################

package MyApp::Schema::DB::Result::Incident;

#...

__PACKAGE__->table("incident");

__PACKAGE__->add_columns(

  "id",

  { data_type => "integer", is_auto_increment => 1, is_nullable => 0 },

#...

);

__PACKAGE__->set_primary_key("id");

__PACKAGE__->might_have( incident_info => 'MyApp::Schema::DB::Result::IncidentInfo' );

1;

########################################

package MyApp::Schema::DB::Result::IncidentInfo;

#...

__PACKAGE__->table("incident_info");

__PACKAGE__->add_columns(

  "incident",

  { data_type => "integer", is_nullable => 0 },

  "info",

  { data_type => "text", is_nullable => 1 },

);

__PACKAGE__->set_primary_key("incident");

__PACKAGE__->belongs_to( incident => 'MyApp::Schema::DB::Result::Incident' );

1;

########################################

package MyApp::Form::Incident;

use HTML::FormHandler::Moose;

extends 'HTML::FormHandler::Model::DBIC';

with 'RenderFields';

use DateTime;

has '+item_class' => ( default => 'Incident' );

has_field 'id'         => ( type => 'Hidden', );

#...

has_field 'incident_info.info'              => ( type => 'TextArea', cols => 50, label => 'Info',

        title => 'Commentary, Information and Background Notes', );

Then in the template, something like...?

[% form.render_field('incident_info.info') %]

--
“Waiting for perfect is never as smart as making progress.”  -- Seth Godin

[Patrick Meidl]

On Wed, May 09 2012, will trillich <will.t...@serensoft.com> wrote:

> Short version: table "incident" might_have an instance of table
> "incident_info" which has incident_info.id that refers to incident.id, and
> incident_info.info, a text-blob field. What code is required to render the
> related info.info field as an optional field in the incident edit-screen?

you should be able to solve this using a proxy in DBIx::Class. see the
pod for DBIx::Class::Relationship::Base (search for 'proxy').

disclaimer: I use this technique for 'belongs_to' relationships myself,
and it work's fine there. 'might_have' is a one-to-one relationship, so
I'd expect it to work there in the same way, but I haven't tested it.

> ########################################
> package MyApp::Schema::DB::Result::Incident;
> #...
> __PACKAGE__->table("incident");
> __PACKAGE__->add_columns(
> "id",
> { data_type => "integer", is_auto_increment => 1, is_nullable => 0 },
> #...
> );
> __PACKAGE__->set_primary_key("id");

> __PACKAGE__->*might_have*( incident_info =>

> 'MyApp::Schema::DB::Result::IncidentInfo' );

add a proxy attribte to the incident_info relation:

{ proxy => [ qw(info other_field_in_incident_info) ] }

> ########################################
> package MyApp::Form::Incident;
> use HTML::FormHandler::Moose;
> extends 'HTML::FormHandler::Model::DBIC';
> with 'RenderFields';
> use DateTime;
>
> has '+item_class' => ( default => 'Incident' );
> has_field 'id' => ( type => 'Hidden', );
> #...

> has_field '*incident_info.info*' => ( type => 'TextArea', cols

> => 50, label => 'Info',
> title => 'Commentary, Information and Background Notes', );

here, you treat the proxied fields as if thery were in the incident
table itself:

has_field 'info' => (...);

> Then in the template, something like...?
> [% form.render_field('incident_info.info') %]

same here:

[% form.render_field('info') %]

HTH

patrick

--
Patrick Meidl ........................ +43 1 9688226 (home)
Pazmanitengasse 4/10 ................. +43 680 2072780 (mobile)
1020 Wien ............................ pat...@pantheon.at
Austria .............................. http://pmeidl.homelinux.net/
--

[will trillich]

Excellent, that did the trick -- thanks, Patrick!

Now... how do we keep from creating empty incident_info records? When there's no data in the $c->req->params->{info} field, we don't want to create empty $item->info ($incident->info->info) records. Is there a straightforward way to preproces the %params?

--
You received this message because you are subscribed to the Google Groups "formhandler" group.
To post to this group, send email to formh...@googlegroups.com.
To unsubscribe from this group, send email to formhandler...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/formhandler?hl=en.

[Patrick Meidl]

On Wed, May 09 2012, will trillich <will.t...@serensoft.com> wrote:

> Now... how do we keep from creating empty incident_info records? When
> there's no data in the $c->req->params->{info} field, we don't want to
> create empty $item->info ($incident->info->info) records. Is there a
> straightforward way to preproces the %params?

in my experience, HFH/DBIc handle empty relations as expected (at least
this works for regular relations). do you really get an empty info item
inserted into the db?

[will trillich]

Patrick -- it doesn't create empty records when the field is left blank, and it does inject NULL when an existing-data field is cleared out. (We were hoping it'd delete the related record when the field gets nulled.)

So all is good in "might_have()" land. :) Thanks!

--
You received this message because you are subscribed to the Google Groups "formhandler" group.
To post to this group, send email to formh...@googlegroups.com.
To unsubscribe from this group, send email to formhandler...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/formhandler?hl=en.

[Patrick Meidl]

On Mon, May 14 2012, will trillich <will.t...@serensoft.com> wrote:

> Patrick -- it doesn't create empty records when the field is left blank,
> and it does inject NULL when an existing-data field is cleared out. (We
> were hoping it'd delete the related record when the field gets nulled.)

you could handle the deletion of the related record with an 'around'
modifier for update_model(), see

https://metacpan.org/module/HTML::FormHandler::Manual::Cookbook#Additional-changes-to-the-database

> So all is good in "might_have()" land. :) Thanks!

great :)