On Tue, 12 Feb 2002, Vadim Gritsenko wrote: > > 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)?
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
