cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [RT] reconsidering pipeline semantics
Date Mon, 08 Jul 2002 14:36:34 GMT
Good post.  My comments interspersed (I just got back from vacation,
so maybe the points were already made):

> From: Stefano Mazzocchi [mailto:stefano@apache.org] 
> 
> In light of the discussion on blocks, Sylvain pointed out 
> that cocoon services should be mapped to pipelines and not to 
> resources directly.
> 
> This consideration triggered a few RT that I would like to 
> share with you and trigger further discussion.
> 
> NOTE: this is nothing related to blocks or flow, but only at 
> the sitemap semantics.

Difining the pipeline.


> What is a pipeline
> ------------------
> 
> We call 'Cocoon pipeline' the collection of all filters 
> (transformers) and adapters (generator and serializer) 
> because there cannot be a pipeline without adapters.
> 
> I think it's time to challenge this concept.

I agree, but not necessarily in the way that you might be thinking.

> What are sitemap resources?
> ---------------------------
> 
> Let me tell you: they are a mistake, a mistake I did trying 
> to reduce the sitemap verbosity and fixing a problem that 
> didn't yet emerged at that time. Early optimization is the 
> root of all evil and I see that
> now: resources overlap with pipelines.

I agree on the statement of early optimization.  I have not used
resources or views (with the exception of link crawling).

However, consider which is clearer to the user:

* Dynamically generating a pipeline based on runtime parameters or
  URI.
* Statically selecting the resource based on runtime paramters or
  URI.

Resources do not necessarily reduce verbosity, but they clarify the
end result.  The problem is not pipeline vs. resources, but the mixing
of the concepts.

I have had the pleasure of working on a rats nest.  It mixed OO
design, procedural design, and a quasi finite state machine that
spanned four objects (states where controlled by static integers).
The thing functioned, it did its job (sort of).  Trying to understand
it requires the equivalent of three doctorates and 5,000,000 years
of experience.  My solution: scrap it and start again.  The new version
still has some bugs to work out, but it is *much* easier to understand.

Under the hood, Cocoon is firmly entrenched in the pipeline semantics.
This is good.  It helps make the components very flexible and powerful,
without having to learn several different ways of doing the same thing.

The problem is that the sitemap exposes everything underneath to the end
user.  It would be much better if the sitemap markup EITHER supported
the
resource/view paradigm OR purely the pipeline paradigm.  The resource
would specify the pipeline fragment that starts the pipeline.  The view
would specify the fragment that ends the pipeline.

It helps with the formalization of a *component* model for web
applications.
There is still the matching/selecting section of the sitemap, but
instead
of dynamically assembling a pipeline as it goes, it uses resources, and
then
selects the view.

What would really help is if the component definition were in one file,
the
resource definitions and view definitions were in a second file, and
lastly
the matching/selection logic were in a third file.  Each of the files
would
have a purpose (SOC).  We would know what we are editing with each of
the
resources.

The logic, or sitemap file is what calls the resource and selects the
view.
In essence, we could set up a really simple sitemap like this:

<map:sitemap>
  <map:match pattern="*.*">
    <map:resource name="{1}"/>
    <map:view name="{2}"/>
  </map:match>
</map:sitemap>

It's really easy to understand.  There is no notion of separate
pipelines,
although they can be implemented under the hood.

The problem with sitemap verbosity is not so much what it represents,
but
that it mixes the representation paradigms to the user.  That makes it
more
complex to understand than necessary.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message