Re: Optimising #include creation of FastWriter

On Wed, 8 Mar 2006, Eric B. Ridge wrote:

| I've been thinking back to when I write IncludeDirective and I simply cannot
| remember why it makes a new FastWriter.  Was it because the old ParseDirective
| did that and I was just coping it?  Was it out of sheer stupidity?  Or maybe
| some reason about not wanting to muck with the real FastWriter in the event of
| a parsing/evaluation exception.  I dunno.

You should have commented it in the code.

..

One comment about the FastWriter/Writer thingy: A "resetable" writer would 
be fantastic, preferrably having unlimited resetable space (just growing 
adding byte-arrays into some list as needed).
  I am responsible for a portal, which renders every portlet in its own 
context and with its own "StringWriter", so that if it throws an 
exception, I can throw it away, and instead render an error-portlet. If 
all goes well, I commit the fully rendered portlet to the FastWriter, and 
move along.

However, this would be hugely better if I could just _always_ pass along 
the same fastwriter recursing down includes and macros and whatnots. 
Before I venture into the next portlet, i do a mark(). Then I let it 
render the portlet, with its recursing. Then if an exception turns up, 
I'll just do a reset(), and then output an error-template instead, while 
if it goes well, i'll do a _flush()_ to commit the stuff all the way to 
the browser at the other end of the stream (I feel this should be up to 
me, the webapp writer, to decide when to flush). That would have been 
absolutely great, and absolutely more performant.

Regards,
Endre.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642