In continuing my work on this template system, I've run
into another problem.
Any one or more of the components can be a script, and the
problem with the existing system which I'm trying to solve
is catching redirects by them. The order in which I'm
doing things is now:
( 4 part handler )
Part 1: Get the template set id (int), title, and meta
designations from
the requested file. Put this list in pnotes.
Part 2: Add to that list the header, footer, toolbar, and
content files as
as designated in the template file.
Part 3: Run through the list of components, and execute
anything that needs
to be executed. Capture the output and put it in
pnotes.
Part 4: Check for redirects, and send one if it exists. If
not, print the
template filled in with the output from the list
entries.
I had previously been executing component scripts like
this:
($file is an entry in the list from Parts 1&2. All entries
in that list are full pathnames. $args is a list of
parameters set up previously in the handler.)
if ( -x $file ) {
$file =~ s/\/www\/html//o;
$file = $file .'?'.$args if $args;
my $subr = $r->lookup_uri($file);
$subr->handler('cgi-script');
$subr->run();
return;
}
This doesn't work especially well anymore, as $subr->run
outputs to the browser. I've looked through past list
messages, and from what I've read there's no way to
suppress that.
Is there a reason that no one has come up with a method for
doing this? It seems like a few people have asked about
it, are we all going about things the wrong way? I'm not a
C guy, so I'd probably need a little guidance, but I'd be
happy to work a patch if no else wants to.
Barring that, what's the best way to do what I need to
do? exec'ing (and it's cousins) the scripts doesn't sound
pretty, but I'm at a loss on what else to try.
thanks,
Todd
At 12:29 AM 10/30/00, Todd Finney wrote:
>This is a follow-up on a question that I asked a couple of
>months ago. The subject was "executing a cgi from within
>a handler (templating redux)", dated 8/23/00.
>
>The gist of the matter is that we need a handler which
>will serve html pages ('content files') inside of other
>html files ('template files'), while sticking other files
>and scripts ('component files') into the template at the
>same time. Quasi-frames, if you will. We've already
>covered why we didn't pick one of the readily-available
>packages to do this.
>
>We've had a working handler that does _almost_everything
>it needs to do. When the user requests a page, it figures
>out which template to use (based on the page requested),
>which component set to use (based on the user and the
>page), rolls the whole thing together and sends it along.
>
>The wrapper can handle both static files and scripts as
>components or content files, and works really well most of
>the time. However, we've run into a problem when a page
>needs to redirect after execution, such as a login page.
>
>The problem is that when a component or content file is a
>script, the server executes that script when it encounters
>it in the template, a'la
>
>- hey, the user wants foo.html
>- the user is a member of group 'coders', and their
>component path is
> /www/htdocs/components/coders/
>- foo.html wants template set 1,
>- go get /www/htdocs/components/coders/tmpl_1, and open
>- begin printing the template file to the browser. As the
>file goes by,
> watch for <[tags]> containing insertion points.
>- hey, there's <[head]>, print or execute
>/www/htdocs/components/coders/head_1
>- hey, there's <[tool]>, print or execute
>/www/htdocs/components/coders/tool_1
>- hey, there's <[cont]>, print or execute foo.html
>- hey, there's <[foot]>, print or execute
>/www/htdocs/components/coders/foot_1
>- finish printing /www/htdocs/components/coders/tmpl_1 and
>close
>
>If /www/htdocs/components/coders/tool_1 has a redirect
>call in it, it's too late for the browser to actually do
>anything about it.
>
>I managed to corner Nathan in New York (thanks, Nathan!).
>He recommended a two-stage handler, one that processes the
>components and content, and another that actually handles
>the printing. Using $r->notes, the second handler could
>be aware of what it needed to do before printing
>anything. This is a really good idea, but it's turning
>out to be more difficult than I anticipated.
>
>The only way I can think of doing this is adding a third
>handler, in the middle, that executes any scripts and
>stores the output somewhere. Then it would check the
>output for a Location: header and set something like
>$notes->{'redirect'} if it finds anything. The third
>handler would then check that value before printing
>anything. If it's there, do it; if not, grab the output
>and the static files and print them to the user.
>
>I'm concerned about putting large amounts of data into
>$r->notes. Some of our script output can be pretty
>heavy. If $r->notes can only take simple strings, how
>large of a simple string is it safe to put in it? Is
>there a better way to do this?
>
>cheers and thanks,
>Todd
>
>
>
>
>
>
>
>
