> -----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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
