Re: [WebMacro-user] Optimising #include creation of FastWriter

[Alex Twisleton-Wykeham-F. <al...@fi...>]

On Thu 9 March 2006 17:00, Endre St=F8lsvik wrote:
> 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.

It's not going to be extending FastWriter because after a cursory look at t=
he=20
code it appears to be caching small (<4k blocks) of binary data in the=20
=46astWriter and then pushing them out to the underlying OutputStream whene=
ver=20
it needs to get it's internal buffer into some kind of known state.

Therefore if it had already pushed data out to the OutputStream when you tr=
ied=20
to rollback your code to the last point then it would fail because it would=
=20
no longer have access to or control of the data.

To do this properly you would need to maintain a single data structure that=
=20
holds the entire contents of whatever is written to it in memory and then=20
shifts it out once you've satisfied yourself that it isn't going to need to=
=20
rollback.

I don't think that you are going to do this by extending FastWriter - it ju=
st=20
doesn't feel right.  Unfortunately great chunks of WebMacro are expecting=20
=46astWriter as their target output stream so at present you are kind of=20
stumped.  Might be interesting to look at what the difference is between=20
Writer and FastWriter and refactor the calling code if it is not too much=20
hassle?

However, the more I think about it, the more I feel that this "rolling back=
"=20
is not a nice idea, for the following reasons:-

=2D the success / failure thing should be a javaspace thing and to only hav=
e it=20
occur inside the middle of a portlet feels a bit odd to me.  I kind of feel=
=20
that when the portlet rendering template is invoked, that the context shoul=
d=20
already contain a set of calculated portlets (or error portlets) that refle=
ct=20
the state of the system.  Then the rollback is just not necessary.

=2D rolling back the output is only half of the problem.  webmacro code can=
 make=20
changes to the state of the backend java system and to the state of the=20
context.  Just because you roll the output stream back doesn't mean that th=
e=20
java and context are in any way in a consistent state with what they were=20
before the rollback point.  To imply that they are is just tempting fate...

Just out of interest - how were you envisioning this rolling back happening=
? =20
Was it going to be a java space action or would it take place during the=20
template rendering phase?

Alex