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]
