> From: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)
[mailto:[EMAIL PROTECTED]]
>
> 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)?
> 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.
> 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.
> 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?
> 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.
The Cocoon's minimum is defined by:
Redirector redirector,
SourceResolver resolver,
Map objectModel
before pipeline starts, and by:
SourceResolver resolver,
Map objectModel
when pipeline processing is started.
> 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.
Can you read twice the same InputStream? I doubt it. Then you won't be
able to use more than one and only one Adapter. What's the point in such
abstraction then?
Hope you find my questions reasonable, as I sincerely trying to get what
you are driving at,
Regards,
Vadim
> 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]
