cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <kinga_dziembow...@hp.com>
Subject RE: Dispatcher/Adapter
Date Fri, 08 Feb 2002 19:19:08 GMT
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Friday, February 08, 2002 1:17 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Dispatcher/Adapter
> 
> 
> Vadim Gritsenko wrote:
> 
> > Looking at all this I see an opportunity to rewrite all SQL / LDAP /
> > XMLDB / Include / I18N / Lucene / etc transformers as a single
> > Dispatcher and a bunch of handlers, reacting on namespaced tags, and
> > working on a SAX stream. What do you think?
> > 
> > On the other side, it reminds me somehow about reactor 
> pattern in the
> > Cocoon 1 and that it was not good enough for some reason...
> 
> I had the exact same feeling when I saw the proposal and I 
> would not be
> happy about accepting such a donation without some previous
> community-driven design phase that might outline the design 
> problems of
> the dispatcher concept.

I am heppy to not have any "previous" fellings.
I do have new ideas...
The Dispatcher/Adapter concept can be used to achieve better separation
between presentation and contents.
Vadim vision will be helpfull in what I am about to describe.
In general the JSP/XSP way of creating dynamic contents is good from the
quick development point of view.
It is not so good from the maintenance point of view as well it still mix
the pres and logic ( at least allows to).

I remember from my old cgi web development an very simpe but powerfull way
to generate dynamic contents with 100% separation of presentation and
context. In fact the application was 100% database driven.
 
The web site was composed by a set of static html templates. In the
template, at the places where dynamic contents should be injected special
markers were placed. The request for the page come, the cgi program reads
the template copiyng the contents to the output stream. At this same time it
was looking for special markers. When the marker was found specialized
object was involved to gather needed dynamic contents. The dynamic portion
was serialized to the outputstream replacing the marker, and the processing
of the template continued.

It was extreamly clean and easy to modify.
This model can be very easily implemented in Cocoon. Source document with
special marker tags, streamed to the pipeline, when marker is found
(dispatcher) the specialized java code 
(Adapter/Handler) in involved. The result streamed to the flow until next
marker is seen etc. 
This way presentation is kept in xml representation ( artist can own this
part ) logic is encapsulated in java code and dynamically invoked. The
contract between the two is the format of marker.

Kinga
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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


Mime
View raw message