> -----Original Message-----
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, February 09, 2002 11:29 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Dispatcher/Adapter
>
>
> > -----Original Message-----
> > From: kingadziembowska [mailto:[EMAIL PROTECTED]]
>
> <snip/>
>
> > Thanks for clarifications. For Adapter, the better place for
> registration is
> > cocoon.xconf . I am glad that it is possible. This way the sitemap
> protocol
> > is not violated, the modifications to the sitemap "family"
> of objects
> is not
> > needed. Simple and clean.
> > Done.
> >
> > Now what we do with the
> HttpServletRequest/HttpRequest/Request problem
> ?
>
> Kinga, I would like to propose you following changes to the
> interfaces.
>
> 1. Dispatcher is the transformer in its essence. Then it would look
> like:
>
> public interface Dispatcher extends Transformer {
>
> }
>
>
> 2. Adapter in its essence is the XMLPipe operating in the sitemap
> pipeline, and reacting on certain XML element:
>
> public interface Adapter extends XMLPipe, SitemapModelComponent {
> String ROLE = "org.apache.cocoon.processing.adapting.Adapter";
>
> String getNamespaceURI();
> String getElement();
> }
>
> It should be possible to write adapters reacting on the root element
> also.
>
>
> 3. If you are all in DOM, you can create DOMAdapter:
>
> public abstract class DOMAdapter extends DOMBuilder
> implements XMLPipe,
> SitemapModelComponent {
>
> Node process(Node node) throws Exception;
> }
>
> It will create DOM out of incoming SAX stream, invoke process(), and
> stream resulting DOM in to the pipe.
>
>
> 4. Default implementation of Dispatcher can lookup adapters
> provided in
> configure and react on adapter's namespace/element.
>
> public class DefaultDispatcher implements Dispatcher {
> public void startElement () {
> for (all adapters) {
> if(current element is of interest to the adapter)
> // forward all events till closing endElement to this
> adapter
> }
> }
> }
>
>
> This will allow same or wider functionality as you had
> before, and will
> be better integrated with Cocoon's SAX pipelines.
>
> Please comment what does not look Ok to you,
>
> Regards,
> Vadim
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.
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.
Both are able to do something Action between pipeline stages, Adapter from
inside pipeline stage.
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.
Your suggestion for the Adapter is great start of some specific adapter
implementation. 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.
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.
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.
For the HttpServletRequest/HttpRequest/Request problem - the fact that I am
not using any other methods that get/setAttribute does not mean anything.
The discussion is about fundamentals not specific usage in the simplistic
example. The Adapter or Dispatcher may need to access some information
associated with the transport on which the request was sent, including for
example InputStream for some reason. When you expose some public interface
you try to make this as usable as possible with the minimal number of
dependencies. My preferred choice will be HttpServletRequest and I said
already why. I am able to compromise this to use Cocoon abstraction but it
cannot be Request ( as it is today ) it does not expose all
HttpServletRequest definitions.
Kinga
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
