[jifty-devel] Dispatcher: difficulties with it beyond the doco and example 1-liners

[Andrew Sterling Hanenkamp]

Steve,

It appears to me that you're trying to "out-think" Jifty or trying to get
into the details of guts where Jifty provides high level tools so you
shouldn't have to.

On 10/14/07, Steve H <s_t_e_v_e_h at hotmail.com> wrote:
>
>
> Hi
>
> I'm still having difficulty with Jifty design. Seems as though I should be
> using the Dispatcher to architect and manage the flow between the various
> windows/fragments.


You are correct, the Dispatcher is the place to stick any code that glues
things together. You use the Dispatcher to help make flow decisions, setup
information to pass on to your views, and it ends up (at least in my apps)
being the repository of everything that doesn't really belong anywhere else.

Please correct me if I'm making wrong assumptions and/or help with some
> detail.  There are bits of it that don't appear to function as I'd have
> anticipated.
> I figured on having Dispatcher code that would leverage 'before', 'on',
> etc code blocks, within which I'd peek at the 'request' and any submit vars
> for context and then 'show' the various fragments that were relevant...


It looks like you're trying to submit a form, but haven't created an Action
to handle the form. You probably want to look into Jifty::Action and
Jifty::Manual::Actions. Also, for every Model, Jifty automatically builds a
nice search action for you, which may obviate the need to create your own
(see Jifty::Action::Record and Jifty::Action::Record::Search).

for example a Search form from one fragment, when submitted, might rewrite
> the search entry field/fragment and then display the searched/found summary
> data into a different fragment that uses a Collection/pager;  clicking a
> link on one of those summary lines in that fragment could a different
> fragment to update showing details.
> So I follow what seems to be implied by the docs and examples...  firstly
> outputting debug from the Dispatcher to verify I'd trapped the correct
> Jifty->web->request->path  ... then I wanted to ensure the correct context,
> so I tried a get('Srch') .. which Data::Dumper indicated was undef.  ...so I
> had a look at the Dispatcher.pm module, and it indicated the get() was a
> call to Jifty->web->request->argument ... so I called that, and similarly
> got undef.  I do however see the Srch arg buried in the data dumped from
> Jifty->web->request->arguments
> >From debug statements in the Dispatcher, per:
> before '*' => run {
>         print STDERR "DBG: ...
> }
>
> DBG: REQUEST: before *  get Srch: $VAR1 = \undef;
> DBG: REQUEST: before *  request->argument(Srch): $VAR1 = \undef;
> DBG: REQUEST: before *  request->arguments: $VAR1 = [
>           {
>             'J:A-auto-3c0293afb5c946d01eb6ca2b4df038f3-1' =>
> 'COS::Action::vsr_main',
>             '' => 'Search',
>             'region' => bless( {
>                                  'default_path' =>
> '/fragments/vsr/im_pgr',
>                                  'parent' => undef,
>                                  'default_arguments' => {
>                                                           'Launch' => 1
>                                                         },
>                                  'name' => 'vsr/im_pgr',
>                                  'force_arguments' => {},
>                                  'qualified_name' => 'vsr/im_pgr',
>                                  'force_path' => undef,
>                                  'region_wrapper' => 1,
>                                  'arguments' => {}
>                                }, 'Jifty::Web::PageRegion' ),
>             'J:A:F-Srch-auto-3c0293afb5c946d01eb6ca2b4df038f3-1' => 'HP',
>             'Launch' => 1
>           }
>         ];
>
> This is all pretty confusing.  The more I look at it, the more cross-eyed
> I get, and possibly digging myself deeper into the wrong hole.  What seems
> to be the way to do things per the doco, doesn't give me the
> expected/desired results, making me wonder whether I'm encountering:   a)
> the wrong approach in the first place,  b) misinterpreted
> behaviour/expectation,  c) broken code,  d) on it goes.


Just to help with some of the confusion, Jifty expects a form to be
submitted in conjunction with an Action. This is typically done by running
something like this. (I'm assuming a model named "Frobnicators" exists with
a column named "name" and am using the auto-generated search action for it.)

In the dispatcher:

on '/search' => run {
my $action = Jifty->web->new_action( class => 'SearchFrobnicators', moniker
=> 'search-frobs' );
set action => $action;
}

In the "share/web/templates/search" Mason file (I'm assuming you're still
using Mason templates):

%# Render the form...
<% Jifty->web->form->start %>
<% $action->form_field('name_contains') %>
<% Jifty->web->submit( label => 'Search' ) %>
<% Jifty->web->form->end %>

%# Show the results...
% if (Jifty->response->result('search-frobs')->content('search')) {
% my $result = Jifty->response->result('search-frobs')->content('search');
% while (my $frob = $result->next) {
<p><% $frob->name %></p>
% }
% }
<%var>
$action
</%var>

With some modifications, this form could update a fragment instead of
rendering the results after completely submitted and reloading the page, but
I just wanted to get across the link between form processing and actions.

I hope that helps to answer your question.

Cheers,
Sterling
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20071014/05ec693d/attachment.htm