Coming to a theater near you, Cocoon 2.1: Same Plot, Different Story!
I haven't read anything that sums up the overall design of Cocoon since
the 1.x days. I think it is high time that we do that so that we as
developers know what Cocoon should be. It has grown, and the level of
plot twists and merging of story-lines in Cocoon makes it a daunting
task of learning it. Perhaps this mail can make it to an xdoc, if there
are any enterprising developers who are inclined to do so.
Cocoon is an XML application, with the underlying storyline of rendering
XML documents in multiple ways. For this reason, we have the basic
Generator, Transformer, Serializer chain. However, in Cocoon 2.0 the
plot thickened with the introduction of the Sitemap to control that
process in a much cleaner manner. Our analysis begins there because
it is so important.
-o Scene 1: The Sitemap o-
Sitemap:
I am the end all and be all. To render or to redirect, that is
the question. Whether tis nobler to suffer the slings and arrows of
feature creep, or by tyranical rule end them.
Commentary:
The sitemap's purpose is to decide how to assemble the pipeline. It
takes its cues from the requested URL, and the current environment.
Because of its awesome responsibility, the Sitemap has three supporting
actors: the Matcher, the Selector, and the Action. These are the tools
we were given to determine which component to use for each part of the
pipeline.
The pipeline is an abstract concept, and not a formal role in the play.
It should not be made a concrete player, and should be a dumb servant
of the Sitemap. The sitemap chooses whether it will place a formal
component in the pipeline, or an element from the cache. The decision
of how to use a cache is the decision of the Sitemap, not the pipeline.
(At least in my mind this is how it should be).
-o Scene 2: The Rendering o-
Servlet: Process this request, please.
Sitemap: Minions! Where should I focus my attention?
Matcher: Here, my lord, here.
Action: In that case, I have something to do.
(scuffling in the background)
Action: I have failed my mission, you need to look there instead.
Selector: I have the correct Generator for you.
Matcher: Here are the 3 Transformers and the Serializer.
Sitemap: Good work minions. I already have information from them.
Wait! Transformer #3, you changed. Cache, retrieve information
from GTT!
Cache: Here you are, my lord.
Sitemap: Transformer #3, take these results and give them to Serializer
when you are done.
Transformer #3: Alas, my lord, this is not XML!
Sitemap: Error Handler! turn yourself into Servlet.
Commentary:
The decision process to choose the proper pipeline is not straight
forward. There is alot of interaction between the supporting roles for
the Sitemap. In fact, this interaction is the source of much of the
learning curve that Cocoon requires. My suggestion is to simplify. Let
us go back to the simple definition of the Sitemap: The sitemap chooses
the resource to be rendered based on the environment and the request.
All the rest of the interactions are specific to a particular sitemap.
In essence, the FlowMap could be viewed as just another sitemap--it just
has different semantics. In fact, I might argue that the semantics are
a bit easier to grasp for programmers. The FlowMap does not have any
pretense to being declarative. It is procedural by nature. The Sitemap
in its current incarnation mixes declarative and procedural aspects,
which is another source of confusion.
The XML pipeline is an easy concept to grasp, and is the core reason why
developers are constantly interested in Cocoon. The story of
controlling the flow of information is also compelling, unfortunately we
have not found a good voice for the story yet. Either we pursue a
purely declarative pipeline (as I have suggested with a thread a while
back separating pipeline declaration and only matching based on URI).
The "componentization" of Cocoon will help us in telling the story.
-o Scene 3: The Supporting Cast o-
Generator: I need a Stream for "context://docs/foo/bar.xml".
Resolver: Let me see.... Oh! Context Protocol Handler, where is
"/docs/foo/bar.xml"?
ProtocolHandler: Here, let me give you the handle.
Resolver: Generator, here is your handle.
Generator: I need the XML fragment from XPath "/document/s1/p[3]"
XPathProcessor: Your XML fragment, sir.
Transformer: Give me a datasource!
DataSourceComponent: Here is a connection.
Transformer: How do I translate that into Spanish?
I18N: I have the translation!
Serializer: HTML here we come.
Commentary:
We have so many supporting roles in Cocoon, it is hard to keep them
straight. In fact, I dare say we have so many that not one of us knows
what all we have. We need to make some decisions on how to handle the
situation. Some components are used by only one implementation of a
component, while others are used by many implementations.
We should take stock, and all roles that only support one implementation
of a component should be included with that component as a supporting
class. We should only have as a supporting role components that service
the Sitemap, or supports a number of implementations of Generator,
Serializer, Transformer, and Reader.
All other roles, we should either factor out into other jars that are
included as we need them, or made as helper classes to the one or two
other components it serves. It is something that should be done on a
case by case basis. We need to simplify Cocoon to the point where we
can understand it, and convey what it is in only one or two sentences.
I think part of the feature creep affecting Cocoon is that it is all
things to all people. Therefore, people adapt it to things that were
beyond the original scope. We need to define Cocoon, and its place
in this world. Is it an application framework, or is it an XML
rendering framework--leaving the real logic to J2EE or .NET as they
both can speak XML.
By simplifying, we can also aleviate bottlenecks in the system. Those
bottlenecks are adversely affecting Cocoon's scalability. Part of the
problem is the large number of component types we have. We should not
have even two interfaces that do the same thing, but have different
methods. We need to merge concepts that can be merged, and clean up
what we have. Otherwise, Flexibility Syndrome (FS) will kill this
project and noone will understand it.
-o Scene 4: The Final Farewell o-
Sitemap: Beware the FS, it will kill you! Beware the FS, Beware!
(humor injected to keep you reading)
:)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
