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