<br><br><div><span class="gmail_quote">On 10/15/07, <b class="gmail_sendername">Steve H</b> <<a href="mailto:s_t_e_v_e_h@hotmail.com">s_t_e_v_e_h@hotmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>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?
</blockquote><div><br>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.<br><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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?)
</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>Ok, so is this indicating that 1) I define an action in the Dispatcher rather than needing a separate .../Action/search-
<a href="http://frobs.pm">frobs.pm</a><br>and 2) that following the new_action, I could have used get('name_contains')?</blockquote><div><br>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.
<br><br>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 Jifty::Result:<br><br>package App::Action::MyAction;<br># param schema and such...
<br><br>sub take_action {<br>my $self = shift;<br>my $name_contains = $self->argument_value('name_contains');<br># do something useful...<br>$self->result->message('Successfully did something useful.');
<br>$self->result->content( name_contains => $name_contains );<br>}<br><br>In this case, if you'd instantiated the action with a particular moniker (I use "my-action-moniker" here), you could perform:
<br><br>on '*' => run {<br>my $name_contains = Jifty->web->response->result('my-action-moniker')->content('name_contains');<br># make a decision regarding $name_contains<br>};<br><br>
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.<br><br>Cheers,<br>Andrew<br></div></div><br>