Berin,
I don't have high enough rank or knowledge of Cocoon to discuss this
subject and should probably stay quiet, but since no one else seems to
respond,
I'll take the risk.
1) If you have been following the threads on HTML form binding and
validation, you have noticed that one problem is how to branch the pipeline
based on transformer output. Two proposed solutions emerged:
a) Implementing a Transformer with a "side-effect" of sticking in the
sitemap a parameter which hints the result of the actual transformation
b) Implementing an XPath selector, which evaluates its test attribute
against the result of the preceding transformation. I'm actually a bit
surprised that threre isn't one implemented yet. After all the user's guide
says: "The selector syntax is similar to the XSLT <xsl:test/> element". I
know that the current Selector interface doesn't allow access to the SAX
stream, but shouldn't that change?
It sounds to me that these are both somewhat in line with your proposed
extension. If so can you elaborate a bit more on the subject with more
implementation details and sample scenarios, say some multi page web wizard.
2) XSL is a pure functional language. As such it carries one of the main
properties of these languages. There are no side effects. No matter how many
times a stylesheet is called with the same input document and parameters,
the output will always be the same. This extends to the following:
"Applying subsequent transformations over a document can be optimized to
only process the parts of the document which changed". Many web pages are
mostly static and they have a few dynamic sections which change from one
display to the next.
Cocoon's <aggregator> component allows for "manual" processing optimization,
when the changes are known upfront and this allows for better caching of
separate parts, which don't change together.
Having working implementations of pure functional languages for over 10
years now, I would expect that the "HotSpot" version of XSLT is not too far
from reality.
Is your callback mechanism a generalization of the <aggregator> component
and a way to hint dynamic parts?
If I understood correctly, if a callback returns the same document (same
content) as it did once before, then eventually a "smart" XSLT processor
(which cached earlier results) would still know that its (the callback's)
portion of the document didn't change and shouldn't be re-processed.
I guess you had enough of my philosophical outburst.
Your turn.
Cheers,
Ivelin
----- Original Message -----
From: "Berin Loritsch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 15, 2002 8:55 AM
Subject: [RT] CallBack Style XML Handlers
> In our quest for componentizing Cocoon, and making it work like a well
> oiled machine for production environments, I got to thinking about
> compiling the entire cocoon component into one large entity. In
> order to realize dynamic aspects of the system, we need a callback
> interface. Sort of a tangential CallBackListener to handle those
> types of events and embed XML fragments into larger documents.
>
> This works slightly different than the current form where we have
> one pipeline of ContentHandlers. Each ContentHandler takes the
> incomming XML and performs some manipulation on it, passing the
> result to the next ContentHandler in line until we get to the
> Serializer.
>
> A side affect of this approach is a multiplicity of cache entries
> based on session information and parameters for dynamic page content.
> It would be more efficient to have one cache entry and a callback
> mechanism to retrieve the necessary XML fragment. We can potentially
> speed up the entire system by at least a factor of 2 (rough guestimate).
>
> The way it would work is this:
>
> The only data type we work with is the XMLSource. The XMLSource acts
> as a generator for the next stage. The XMLSource can be a
> ContentHandler that forwards events to the next ContentHandler in the
> pipeline, OR it can be a CompiledXMLSource used in the Cache area
> that calls the events as necessary. The interface looks something
> like this:
>
> interface XMLSource
> {
> handle( ContentHandler ch );
> }
>
> -o-
>
>
> THE TIP OF THE ICEBERG
>
> By working strictly with XMLSource, we don't care if the source is a
> ContentHandler or an InputStream. All we care about is that the
> information is sent to the next level. What it allows us to do is
> implement a WriteBack style caching system. In essence if we have a
> call for the URL "/news.html" we make all calls through the XMLSource
> Resolver. The Resolver is able to work with the cache to compile the
> XML at various stages of its growth. That way we can realize the dream
> of optimizing away any and all transformations up to this point. In
> essence, we can choose the XSLT parser based on operational correctness
> because the Cache has compiled the result for us anyway.
>
> So how does this work with dynamic content? Good question, and this is
> where CallBack XML handlers work. By embedding CallBack events into the
> compiled XML, we can generate the dynamic portions of the page at will.
> Furthermore, we can set the system up so that callbacks are generated
> asynchrounously and accessed via the XML Resolver mechanism. The
> information will at least have a periodicity of one request. The XML
> fragment can be requested multiple times, but only generated once.
>
> -o-
>
> THE REALLY COOL STUFF
>
> By having the system work in this way, we solve another issue that has
> been plaguing us. How do we create dynamic systems that are easy to
> write and maintain. We have been focusing on using namespaces to mark
> dynamic information like XInclude or ESQL. While they are decent
> develomental tools, practice has shown that they don't scale as well
> when you have to merge information from many datasets. The truth is
> that the person who is writing everything typically will not remember
> 5 different namespace declarations. I personally have to go back and
> copy the XML namespace declarations from other pages.
>
> The callback mechanism allows us to embed events using only one
> namespace for all dynamic logic. We would leverage the development
> effort in Excalibur's scratchpad with the event based architecture
> support systems. The CommandManager processes the actions as they come
> in (with a controlled number of threads that are a function of the
> number of processors on your machine). The interface for the callback
> is simple. We extend the Command interface with XMLSource interface:
>
> interface XMLCallBack extends Command
> {
> XMLSource getFragment( Parameters paramList );
> }
>
> The only thing we have to look out for is the XML event:
>
> <call:event type="newsFlash">
> <call:parameter name="example" value="Business"/>
> </call:event>
>
> We would have to extend the compiled XML to resolve these into one
> callback method like this:
>
> interface CallBackHandler
> {
> event( String type, Parameters paramList );
> }
>
> We kill a number of birds with one stone. We have a natural feel
> for embedding dynamic pieces of generation, while maintaining the
> ability to precompile the XML at each stage of the game. By extending
> the Compiled XML spec to have one more callback type, we defer the
> dynamic portions to controllable classes.
>
> Furthermore, the sitemap controls the pipelines that the XMLSource
> fragments go through. In essence allowing us to precompile those as
> well.
>
> In the end, it is conceivable to go so far as to specify a Compiled
> Stream protocol that has CallBacks. We can explore compiled components
> at just about any level. However, this approach helps solve some
> immediate needs, as well as allows us to use the existing components
> to generate our XMLSources. Hopefully we can explore methods of
> generating CallBack fragments from XSP pages, allowing us to use that
> approach in a more efficient manner.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
