Is HFH appropriate for creating forms to query data?

[Steve Schafer]

Synopsis - I have a table 'RequestHistory', and wish to build several
reports broadly based on this one table. In each case/report there
may be several criteria that the user may wish to enter to filter the
results that the report will be based on (think date ranges).

The main issue? is that there is no storage of the form contents/
fields. I'd like to use some of the validation and rendering
functionality that HFH provides, but don't see any examples of this
type of usage, nor any substantive mention in the docs.

Any pointers would be appreciated!
Steve

[will trillich]

I originally had the same puzzle. But it's a lot more straightforward than you expect. :) Here's my understanding of how the forms work:

If your form DOES include 

   has '+item_class' => ( default => 'App::Blah::Sample' )

then that form will be tied to that DBIx record, so that any data entered into the form will be inserted or replaced (depending on your primary key) in the database when you $form->process( item => $item, params => $c->req->params ) in your app (presuming Catalyst context).

If your form does NOT include "has '+item_class'" then you can use it like a search form, having it alter the behavior of your app, without worrying about the entered data going into your database. You unwrap $c->req->params, using those to specify search parameters.

Also: if your form has fields that do not correspond to database fields, they're simply ignored. It makes it handy to generate read-only or calculated fields for the user's comfort or for general clarity, without worrying about having to choose between no-such-field errors (if it were to gripe about form-fields that don't match database-fields) and heavy rendering code (to otherwise generate inline fields 'by hand').

So, for example:

    package MyApp::Form::DataEntry;

    with 'HTML::FormHandler::Render::Table';

    has '+item_class' => ( default => 'Incident' ); # Tied to DBIx record 'Incident'

    use DateTime;

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

    has_field 'opened' => ( type => 'Date');

    #etc

    has_field 'submit' => ( type => 'Submit' );

    package MyApp::Form::SearchExample;

    with 'HTML::FormHandler::Render::Table';

    # no '+item_class' here, no db record to tie to

    use DateTime;

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

    has_field 'opened_begin' => ( type => 'Date');

    has_field 'opened_end' => ( type => 'Date');

    #etc

    has_field 'search' => ( type => 'Submit' );

Any pointers would be appreciated!

Steve

--
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.

--
"The more you try to avoid suffering the more you suffer because smaller and more insignificant things begin to torture you in proportion to your fear of being hurt." -- Thomas Merton

[Steve]

So... if my form fields represent attributes of an object (Moose, of
course) like 'from_date' and 'to_date', but there is no storage taking
place, would I still call the 'process' method, or rather call the
methods within 'process' (namely 'validate') individually as needed?

On 12/6/2011 12:26 AM, will trillich wrote:
> On Mon, Dec 5, 2011 at 8:33 PM, Steve Schafer <st...@matsch.com
> <mailto:st...@matsch.com>> wrote:
>
> Synopsis - I have a table 'RequestHistory', and wish to build several
> reports broadly based on this one table. In each case/report there
> may be several criteria that the user may wish to enter to filter the
> results that the report will be based on (think date ranges).
>
> The main issue? is that there is no storage of the form contents/
> fields. I'd like to use some of the validation and rendering
> functionality that HFH provides, but don't see any examples of this
> type of usage, nor any substantive mention in the docs.
>
>
> I originally had the same puzzle. But it's a lot more straightforward
> than you expect. :) Here's my understanding of how the forms work:
>
> If your form DOES include
> has '+item_class' => ( default => 'App::Blah::Sample' )
> then that form will be tied to that DBIx record, so that any data
> entered into the form will be inserted or replaced (depending on your

> primary key) in the database when you *$form->process( item => $item,
> params => $c->req->params )* in your app (presuming Catalyst context).

>
> If your form does NOT include "has '+item_class'" then you can use it
> like a search form, having it alter the behavior of your app, without
> worrying about the entered data going into your database. You unwrap

> *$c->req->params*, using those to specify search parameters.

> <mailto:formh...@googlegroups.com>.

> To unsubscribe from this group, send email to
> formhandler...@googlegroups.com

> <mailto:formhandler%2Bunsu...@googlegroups.com>.

[Gerda Shank]

Steve:

You don't have to save your form fields, if that's the question :)

If a form inherits from HTML::FormHandler, and not from
HTML::FormHandler::Model::DBIC (or without the equivalent trait), then
nothing is stored, since there isn't anywhere to store it.

You can get the validated values with $form->value.

But maybe I'm missing the point... If so, could you clarify?

Thanks,
Gerda