[Catalyst] Losing subrequest output

[Nigel Metheringham]

On Tue, 2005-12-13 at 08:05 -0800, Bill Moseley wrote:
> Another approach might be to break your page down into smaller
> templates or template blocks.  Then when processing a full page (like
> in the example above) you "PROCESS select_group0" inline, and for Ajax
> requests then the controller just specifies the template is
> select_group0.  That avoids the need for a subrequest and avoids
> having the view call the controller.

True.  I have slightly more magic in the ajax handler... not sure if I
can just do that in the template, but worth thinking about.

> I have a few Ajax features that duplicate features that are available
> as normal page requests.  In these cases I use the same controller for
> both, but after setting up, for example, the database query I then do:
> 
>     return $c->forward('/ajax_request') if $c->is_ajax;
> 
> which builds and returns a standard list.

Feels like you are moving the controllers round for the presentation -
that was the thing I didn't like about HTML::Template (you did much of
your presentation work in organising data to go into the templater).


> As another example, I also have my main wrapper TT template decided
> how to format pages (include page headers/footers layout) based on
> if a request is an ajax request or not.

Now I did that one slightly differently I think.  The example at
  http://www.dev411.com/wiki/AJAX_Select_Chaining_with_Catalyst

glosses over this by using complete html page templates for the main
page, whereas I would expect that any significant sized project would be
leveraging the TT stuff by using a wrapper and having their individual
page templates just containing the actual content for the page.  Then of
course you need to make sure your AJAX doesn't get a load of additional
stuff wrapped round it.

My wrapper.tt2 is adapted from the stuff set up by
Catalyst::Helper::View::TTSite although the wrapper itself is directly
taken from the Badger book examples for a static TT based website
(shortened - removed additional cases for this mail):-
        [%- SWITCH page.type;
                CASE 'html';
                    debug("Applying HTML page layout wrappers to $template.name\n");
                    content WRAPPER site/html.tt2 
                                  + site/layout.tt2;
        
                CASE 'fragment';
                    debug("Passing HTML fragment through: $template.name\n");
                    content;
        
                CASE;
                    THROW page.type "Invalid page type: $page.type";
            END;          
        -%]

page.type is defaulted to template.type || 'html' within the config
stuff run due to the PRE_PROCESS config element for the View::TT module.

So the AJAX fragments have their first line as:-
        [% META type = 'fragment' %]

which prevents the wrappers being applied.

Like almost everything else to do with Catalyst there is almost too much
choice - which is making it really hard to decide what to do, and is why
Catalyst probably feels so much harder to start with than (say) RoR.
Especially as a load of things depend on the core components you are
using (eg I use DBIx::Class rather than Class::DBI, so a lot of the
examples need a little transformation to use in my system).

If I get an appropriately shaped tuit in the week up to Christmas I'll
put together a modified copy of the select chaining example on the wiki.

	Nigel.
-- 
[ Nigel Metheringham           Nigel.Metheringham at InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]