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

Steve H s_t_e_v_e_h at hotmail.com
Mon Oct 15 22:52:11 EDT 2007

Hi Sterling,
Ta for the response.

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

I was trying to differentiate what to do for a particular URL depending on what data was being passed in... e.g. when the fragment is called to render initially compared to when a Submit has occurred from that fragment, and/or from a link from a pager.

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

I've read all the doco... a number of times.  It doesn't provide a whole lot of insight (for me at least) into design patterns... so I seem to get tied into knots trying various permutations of what seems to be described in the doco.  What I've found as really benefitial are the various Apps from the SVN...  in fact some of yours seem really helpful (e.g. CASPlus), although I only got to them last night and haven't yet got to refactor my prototype stuff from examples.

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?
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?)

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

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')?

> 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...
> %# 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) {
> % }
> % }
Overpaid or Underpaid? Check our comprehensive Salary Centre

More information about the jifty-devel mailing list