cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject RE: Dispatcher/Adapter
Date Tue, 12 Feb 2002 20:31:22 GMT
On Tue, 12 Feb 2002, Vadim Gritsenko wrote:

> > From: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)
> [mailto:kinga_dziembowski@hp.com]
> >
> > Vadim,
> >
> > Lets make clear that the core elements are:
> > In the Adapter "family":
> > Adapter.java
> > AbstractAdapter.java
> > AbstractComposerAdapter.java
> > AbstractComplementaryConfigurableAdapter.java
> >
> > In the Dispatcher "family":
> > Dispatcher.java
> > AbstractDispatcher.java
> >
> > Everything in the demo package is just a simple "real"
> > extension and usage. Let's start with the Adapter.
> > Adapter is an entity able to do something, using HttpRequest
> > as a means to exchange the information.
>
> Why HTTP request? It makes this concept totally useless in any other
> environment. How it would operate in JMS environment? EJB environment?
> Non-HTTP servlets (e.g., maillets)?

This is exactly the point why we have those abstractions.

To take the concrete sample of Kinga's Adapter/Dispatcher concept, even
the SOAP spec dosn't really care about environments as there are
different transports proposed to work )i.e. SMTP). So why should the
Adapter/Dispatcher have the need for such specific interfaces like
HttpServletRequest?

> > Anything can be an adapter and it is no specific implementation
> > connected to it at front.
> > Adapter is modeled on Action family and it is big similarity
> > between Adapter and Action.
>
> If Adapter is an action, then just use Action. If adapter like an
> Action, but acts on the XML, then there is a difference. That's why I
> suggested to extend from XMLPipe. In addition to pipe, extending from
> SitemapModelComponent provides you with the same information that action
> has.
>
>
> > Both are able to do something Action between pipeline stages,
>
> Action can not act between pipeline stages.

Absolutely. Actions are pre-pipeline controller logic (to use the MVC
metaphor where the pipeline is the view)

>
>
> > Adapter from inside pipeline stage.
>
> Here I agree with you: Adapter as I see it (ATM) can act between stages,
> on parts of XML.
>
>
> > The concrete adapter implementation can be written by somebody who has
> no
> > Cocoon programming knowledge, as well by the Cocoon programmer who
> will make
> > his adapter integrated to the Cocoon framework.
> > It is an implementation domain not the definition of the interface.
> The
> > interface just standardize the API.
>
> Ok.
>
>
> > Your suggestion for the Adapter is great start of some specific
> adapter
> > implementation.
>
> Here I do not agree with you. It is the most abstract interface, and
> here you can build up more concrete ones, like DOMAdapter. But again,
> may be you just need to explain this in more details.
>
>
> > But I fill strongly that Adapter ( like Action is an
> > interface of its own ). Some Adapter can be XMLPipe operating in the
> sitemap
> >  pipeline, and reacting on certain XML element but can be something
> else
> > too.
>
> Like what? Explain this in more details, so I better understand you.
> Right now I'm under impression that Adapter is "an action on the XML".
> Adapter should return some result, and as we are working with XML, it is
> obvious choice for Adapter to return XML. Adapter also should have some
> input, and it consists (in my current vision) from whatever provided by
> SitemapModelComponent and from input XML.

Acting on XML and returning XML is obiously a Transformer (or an XMLPipe
to be more abstract).

Over the time I smell FS as the Adaptor concept wants to combine all
kinds of interfaces we separated in Cocoon (SitemapModelComponent,
Actions, Transformers).

>
>
> > Now Dispatcher:
> > One of the candidates to be a Dispatcher is Transformer. But not
> > necessarily. The Transformer can became a Dispatccher but not all
> > Dispatchers need to be Transformers. Any pipeline stage which will
> need to
> > dispatch something to somebody can decide to became an Dispatcher.
> Action
> > can be a Dispatcher,
> > Generator can be a dispatcher - let say encryption is needed before
> > generator can pump SAX events to the pipeline.
> > To make things more clear we can change the name of AbstractDispatcher
> to be
> > AbstractTransformerDispatcher as a beginning of the
> TransformersDispatcher
> > implementations.
>
> Ok. Now I'm at loss. Why we need Dispatcer/Adapter for actions? Isn't
> actions are enough? Of course, may be not, then you can show why you
> think it is required there. At the moment, Sitemap/Action already
> implement Dispatcher/Adapter paradigm: sitemap selects an action and
> calls it, same as Dispatcher does with Adapter. Why another level of
> abstraction here?

I can see the dispatching concept/role made into a Avalon Component so
that specific implementations can dispatch anything among a set of
something. But those don't belong to anything in the Cocoon concepts.
Any Cocoon part (Action, Generator, other Avalon Components, etc.) can
use them by looking up the CM.

>
>
> > In general my point is Dispatcher and Adapter definitions should
> assume as
> > little as possible about implementations. Those are open to the
> > implementations and needs.

Sounds like an excerpt from the Avalon handbook :)

Giacomo



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


Mime
View raw message