[jifty-devel] re:Re: Dispatcher: difficulties with it beyond the doco and examples

Andrew Sterling Hanenkamp sterling at hanenkamp.com
Tue Oct 16 02:10:17 EDT 2007

On 10/15/07, Steve H <s_t_e_v_e_h at hotmail.com> wrote:
> I asked a specific question regarding not being able to get the form
> submit data/vars via the Dispatcher's get().  Can I conclude from what you
> are saying, as that I will be able to er, get() the vars only so long as I
> have an action declared specifically for the form in that fragment?

Well, if an input is part of an action, then the only place you can get to
it easily is from that action's take_action() handler using the
argument_value() accessor.

If you set the value using "defaults" on a region or using "args" (which is
used to modify the defaults) on a button or link that modifies a region,
then you can use get() to read it directly since that's what those
parameters are for.

One thing I noticed as I poked around at it was that if I'd specified a var
> as a default arg, then I'd be able to get() it... otherwise not... so it
> became awfully confusing as to what specific circumstances vars will be
> available for get()'ing. (er, can those circumstances be easily described?)

Basically, use  an action when reading in a form and use get() for links
with GET-style/region-fragment parameters. It's really more complicated than
that, but I'd recommend trying to keep it simple and work your way up.
Talking with Jesse about what's required to get a book put together for
Jifty has revealed that there are a lot of layers to Jifty (more than I knew
about). It's best to try and take on a piece at a time.

> Ok, so is this indicating that 1) I define an action in the Dispatcher
> rather than needing a separate .../Action/search-frobs.pm
> and 2) that following the new_action, I could have used
> get('name_contains')?

No. I was suggesting the use of the built-in search actions that Jifty will
automatically build for you as soon as you declare a model. At which point,
you shouldn't need to get('name_contains') because the Action will process
the form and generate a result set you can then render.

However, if you need to make a decision on the basis of the action's
outcome, you could define an action that passes that information back via

package App::Action::MyAction;
# param schema and such...

sub take_action {
my $self = shift;
my $name_contains = $self->argument_value('name_contains');
# do something useful...
$self->result->message('Successfully did something useful.');
$self->result->content( name_contains => $name_contains );

In this case, if you'd instantiated the action with a particular moniker (I
use "my-action-moniker" here), you could perform:

on '*' => run {
my $name_contains =
# make a decision regarding $name_contains

Btw, all new_action() does is instantiate an existing action package (which
may be one automatically generated for your model). It doesn't actually
declare an action class.

An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20071016/ab28e297/attachment.htm

More information about the jifty-devel mailing list