All:
In advance, I apologize for most certainly rehashing the same old crap
but I found no true answer in the list archives or the docs.
I'm a recent convert from another template module mostly for the include
behavior of TT. What I'd like to do is have generic "components" similar
to slashdot's login, poll, etc. included in a large number of pages.
I'll use a login component as an example from here on, but substitute as
needed.
The problem is that these are heavy user interaction "objects", if you
will, so I'd like to keep all flow control and decision making out of
the template. Each component would have its own url (i.e.
/components/login) which would essentially be a multipage mod_perl
handler. Building the handler and making it spit out the desired
templates is simple. My question is what is the best way to squish said
components into the page? Each component would be more similar to a SSI
as they would spit out html chunks and not pages. I can't really use SSI
includes because it is resolved to a filename (I need a "true virtual"
url include). I can't generate static files due to the dynamic nature of
these components.
It seems I have two options:
1. Use something like TT's plugin method. The problem here is that way
too much logic would wind up in a template (too much "C" in the "V")
2. Bypass apache / mod_perl entirely and load the modules into the main
handler (the registered apache handler for the uri) and "simulate" a
mod_perl invocation of the handler by doing something like this:
sub handler($$)
my ($self,$r) = @_;
...
$template_output = My::Site::Component->handler($r);
$tt->process('atemplate', { login_component => $template->output() }, $r);
...
}
The problem with this method is that half of the "controller" code (the
display) is handled by the enclosing page where as the submission must
be handled by your run of the mill mod_perl handler. Essentially, I have
to make sure that the component in question can be invoked in my
"simulated" (or "dispatched", if you prefer) mod_perl handler AND
properly run when called "normally" under a uri. This, of course, leads
to other problems like under MP it should return a status code and when
directly invoked it should return the parsed template.
Either way, you see the confusion. Now, I may be new (about 2 weeks in)
to TT, but I'm not new to MP and (for whatever reason) I've never hit
something as awkward as this. Maybe the answer is under my nose, but all
of these methods (although *could* work) seem extremely difficult to manage.
What I wish I had (as hack-ish as it would be) was a TT directive such as:
[% URI /components/login %}
...that would accept *template* output from a uri AND RECURSIVELY
include it as the INCLUDE directive does. Of course, I could hack this
together with lwp and other nasty-such-bits but that is U-G-L-Y not to
mention expensive.
For the record, I originally was doing this with apache sub requests and
re-tie'ing Apache->PRINT to my own package, buffering the subrequest's
output and including it that way, but that was also extemely nasty to
work with (as taking the tied print from apache just doesn't seem right
and actually seemed to upset MP). Generally speaking, it was like "hiway
robbery output chain" for MP - a yucky thought, all told.
Sorry for the novel and I, once again, apologize in advance for the poor
examples, poor judgement, poor site design - take your pick.
--
eric sammer <[EMAIL PROTECTED]>
LinuxSTEP <http://www.linuxstep.org>
InterfaceWM <http://interfacewm.sourceforge.net>
