cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: [RT] Cocoon subcomponent object model (was: Re: is cocoon symmetry a holy grail?)
Date Wed, 20 Feb 2002 08:59:45 GMT
From: "Stefano Mazzocchi" <>

> Nicola Ken Barozzi wrote:
> > My opinion is that developers are not yet taken correctly into account.
> > While the other three have a componentization which is sufficient for
> > part of work, developers suffer for the lack of it. Usually a developer
> > to write a component, and doesn't have a (sub) component model to deal
> ??? I disagree, you can write avalon-aware sitemap components by hand
> (and many people do just as easy as they write servlets... or even
> better).

Yes, this is right, but I would also like a *sub*Component model.
Components to make Cocoon Components, so to minimize impedence mismatch
between Java and XML.
With Ricardo, we agreed that somehow Java and XML intermingling is bad, and
that they should be separated.
Generators don't do it, and have a fixed schema.

> > Also, Cocoon components do not have scope and filter all events coming
> > in (security: I don't want sensitive tags passing in a transformer that
> > useful but not completely known).
> please, let's get real here: I *strongly* doubt you'll ever use a filter
> in your pipeline that you don't trust. Security is ok, but at this
> granularity becomes a nightmare (and a serious performance limitation)

I tend to agree, but I'm no sys-admin.
This concern came from a boss you know well... ;-)

> > A----------------------------
> > First we have to change slightly the notion of cocoon pipeline
> > introducing scope.
> > Pipeline components need not access <all> SAX events but only what
> > them. This also means that the pipeline coulde be evaluated eventually
> > parallel
> > fashion, improving scalability in heavy processor intensive or high
> > pages.
> >
> > For example let's say that we have this XML:
> > <page>
> > <longquery name="account"/>
> > <query name="username"/>
> > <page>
> > Let's say that in another file (the developer's sitemap) is written that
> > query tags must be processed by the foo.sql.QueryTransformer and the
> > longquery tags by acme.sql.BankTransformer.
> > As SAX events come into action the start page tag is directly sent to
> > serializer.
> > Then the acme.sql.BankTransformer is given only the longquery tag and
> > processing in a non-blocking fashion.
> > This means that SAX events can continue and parallely
> > foo.sql.QueryTransformer can start processing his tag.
> > Now the pipeline has to wait for the first transformer to finish because
> > embedded tags link page cannot be processen in non-blocking fashion.
> > they finish their output events are outputted in order and finally the
> > page tag.
> >
> > As you can see if there are transformers that take longer to perform
> > because of latency of DBs and likes) they can be performed this way in
> > non-blocking fashion, speeding up total response time.
> And this should be KISS?

Ok, so let me explain it from a sitemap view.

You can add a parameter parallel="true" to make queries run simultaneously.

Simple enough?

> > B----------------------------
> > A global context-aware object broker could also be inserted in the
> > This doesn't really change the framework, it's just a useful addition.
> Don't forget we can still use Alberto's X:Forge for this.

Where is it? <hint, hint, nudge, nudge ;-)>

> > C----------------------------
> > Now let's explain how a finer-grained object model can be devised.
> > First of all it must be capable of specifying a pipeline component as a
> > of smaller components possibly only by writing XML described "glue".
> > I's like:
> What you propose is similar to X:Forge and to DXML that Ricardo was
> working on (I say 'was' because I can't reach him anymore :( but was
> much simpler:

Similar yes. I still remember the very interesting brainstorming I had with
them on these.

> I'd rather attach X:Forge to Cocoon (at the generation level) than
> having to write something so complex at the pipeline level.

X:Forge is ok for me, but where is it? Can you put it in the scratchpad?

> I think the tokenize/detokenize part are really far from my view of
> keeping it simple and go into a deep mess.

Ok. Could be true.
Only live code can be really discussed, we'll continue this at that time.

Nicola Ken Barozzi       
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message