Vadim, Let's summarize what is my understanding of the changes you propose.
1. Dispatcher to extend Transformer it is OK modification althrough I still think other components can be candidates to became Dispatchers. 2. The scenario you try to describe is: The adapter express the interest in some XML element, the Dispatcher can query the adapters using String getNamespaceURI(); String getElement(); Dispatcher channels all elements until the end tag to the adapter interested in such element. The adapter, if it is DOMBased collects all events of its interest and using Node process(Node) method is processing the document fragment. At the end of the processing it is streaming the results to the main stream of SAX events. If this is the model you describe I do not have a problem with it. It changes somehow the original design but when I am thinking more about this I understand why you like to make such modifications. For the adapter, the access to HttpRequest/Request will be done through SitemapModelComponent capabilities. Let me know if it is correct understanding. Regards, Kinga > -----Original Message----- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 12, 2002 12:11 PM > To: [EMAIL PROTECTED] > Subject: RE: Dispatcher/Adapter > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
