in reply to Re^2: Output should have multiple segments
in thread Output should have multiple segments

That's how Mason works after all, but using a single output buffer. Ok, that's shallow, I hope the fellow masonites will forgive me for this one ;-)

You should be able to quickly build yourself such a "multi-pass" system using your own conventions, following Mason's request cycle (briefly: gather output by running orderly each component in the inheritance chain)

For the sake of example, here's a possible approach for such an autohandler:

<%doc> # document everything (conventions, hacks etc) :P~ </%doc> <%once> # load modules at this step only if you're not able to load them "a +t startup" # (e.g. preloading them under a mod_perl enabled HTTPd) use My::App; </%once> <%init> # set up runtime/dynamic default configuration parameters $m->comp( '_conf', %ARGS ); # ^ these should all be "notes" ($m->notes) # a <%shared> replacement (yeah, that's me, # I always avoided it for not doing what I meant) ;-/ if ( $m->request_comp->method_exists('_init') ) { $m->request_comp->call_method('_init', %ARGS); } # fetch page content $m->notes( 'page_content' => $m->scomp( $m->fetch_next, %ARGS ) ); # ^ remember that you have to *handle* the "exceptions" # <%cleanup> replacement if ( $m->request_comp->method_exists('_cleanup') ) { $m->request_comp->call_method( '_cleanup', %ARGS ); } # render output return $m->comp( '_render', %ARGS ); </%init>
Also notice that you can optimize this by moving out more app. logic into your My::App modules ;-)