cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Foster <>
Subject Re: [C2] Generator affecting future processing
Date Tue, 06 Mar 2001 18:17:15 GMT
Thnks to Berin for the earlier reply (and sample code!) and to Stefano for
this one.  I'm still trying to understand some of the notions being
expressed (esp. "crosscutting"), but I'd like to toss in some idea as
to where I was coming from and what I was envisioning.

> > Is it possible for a Generator to change the processing chain
> > at runtime?
> No and I'll be *strongly* against making this possible.

What I was initially reacting to was the notion that the processing flow
seemed to be static.  Berin's comment on actions has helped me start to
see this differently.  However there is a alternative view of a web
application that I would like to propose.

Right now I see the sitemap as the setup for a big game of (what
I've seen called) Plinko.  In this metaphor the sitemap can be seen as a
big, vertically mounted sheet of wood with nails driven into it to form
patterns.  When a request comes in it is metaphorically dropped in the top
of the game and bounces along to the botton, taking a path that depends on
the layout of the nails.  Along the path things happen, such as
transformations and serialization.

This reflects the notion of SoC, where one person deals with laying out
the board and another with deciding how each section of the path will
affect the response.

What I was originally looking for was the notion of "Internalization of
Control".  In this case the reply itself is responsible for deciding
what it wants to do next.  The metaphor I have for this is a
restaurant with a smorgasborg.

When a request comes in, it is the equivalent of entering the restaurant.
You then make repeated trips to the smorgasborg, each time choosing a
different dish (transformation), depending on your past and current state.
Eventually you leave (serve the reply).

For some naive reason I see this second metaphor as more OO (or possibly
more Wirth-like) as the request/response object completely encapsulates
it's behaviour, as opposed to having that behaviour imposed on it from

Interestingly, this seems to fit with the suggestion made earlier (I
should turn off digest mode I think) about resolving some of the threading
concerns by encapsulating things into a meta data header.

>> When I was playing with the ScriptGenerator, I thought that it would
>> be nice for the Generator to be also to do things like choose a skin
>> using information from a database.
> No, it's a clear programmer-oriented view of the world and will generate
> concern overlap, thus increase maintenance costs over time.

The intent was for it to be a "data-oriented" view of the world, but I
think I see how it could be interpreted as being "programmer-oriented".

[ snip Berin's suggestion ]
>> The problem with the simple solution proposed above is that some skins
>> might require more than one transformation.  Can a Generator specify
>> transformations in additional to those in the sitemap? Alternatively
>> can a Generator bypass a transformation?
> Generators generate. Period.
> It would be like placing the software to run your computer into the
> powerplant that generates the power just because it would be nice to do
> so from a powerplant engineer perspective.

I see it more as I should be allowed to decide what appliances to use
based on how much electricity costs right this minute (go deregualtion!)
and not be forced to use my dishwasher because the person who designed my
kitchen said I had to.

>> I guess my question is how tightly coupled is Cocoon2 to the sitemap?

Hmmm.  IIRC, the sitemap is compiled to a Java class that is singleton-ed
to provide global flow control.  Couldn't I put in a class that reads the
flow control information from a database (or some kind of visual
representation or something) but provides the same interfaces as the
current sitemap class?

Cocoon2 seems to be tightly coupled to the pretty good notion that there
is a singleton object that decides what should happen to all requests.
The coupling of that object to the sitemap seems somewhat weaker.

Similarly, could (and "shoud" since this is mostly stream of
consciousness) each request/reply object be given a "sub-sitemap" instance
that is responsible for guiding it through it's life?  In this way SoC is
maintained, as there is still a sitemap maintainer, but the granularity
and flexibility is increased.  This might get into flexibility syndrome

>> The  sitemap seems much more static than a complex system (say a
>> web-based e-journal that includes workflow capabilities) might require.
> No, I disagree, it simply forces you to think more at first on how to
> componentize/design your sitemap in such a way that all requirements are
> met.

This is where I get a little bit antsy.  One of the weaknesses I have seen
with OO (or at least the times I've been able to use that modeling style)
is that you have to be really careful with the making upfront modeling
decisions that then turn out to have missed an important aspect or two.
The counter-argument that using loose coupling should allow for changes
sounds nice, but I haven't seen many documented examples of this in
practice. (I think this paragraph is relevant)

Cocoon2 has a very nice set of extremely flexible underlying abstractions,
founded on the notion of XML as a substrate and generic tree
transformations.  I guess in my mind the sitemap is comparatively an
overly static and restrictive entity.

This reminds me of something...I recall seeing the idea that
transformations can be characterized completely by their inputs and
internal state at the time of transformation.  Is this characterization
still being used?  My concern is that a transformation could vary
depending on time of day, contents of a database, or a call to Random().
In each case I agree that the variations could be captured in a static
sitemap, but that won't stop people from writing transformations that
violate the assumption.

I'm concerned that traditional web development shops might diss Cocoon2
because it uses ideas that are very different.  The need for good
documentation and examples seems very high.

>> It certainly rocks for less crazily dynamic situations.
> While designing the sitemap semantics I imagined all the possible
> crazily dynamic situations and I could never find one that was not
> possible to write using a static sitemaps.

"Possible", sure.  What about "straightforward" and "obvious"?  Not to be
too trite, but this seems like a "hammer/nail" situation.

> At ApacheCON in London we had a big discussion over 'dynamic pipelines'
> and nobody was able to come up with an example that *required* this.
> Jason, dynamic pipelines are what Cocoon1 is based on and almost every
> Cocoon1 user knows that reactors are a bad pattern because aspects are
> crosscut too much.

This one I'm going to have to spend more time trying to grok.

I think you're refering to the ability to embed PIs in a document, and in
this case I agree with you that doing so makes things very messy.

Where I get antsy is that I see the sitemap as being "oh so close" to a
full programming language.  It has flow control and the ability to declare
variables, which (since I forget my language courses) makes it pretty
close to turing complete.  Add in the abilty for the various components to
communicate results and status back to the sitemap, and SoC seems to have
dissapeared again.

View raw message