Re: maximum (practical) size of $r->notes

[Todd Finney <tf...@boygenius.com>]

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