I'd like to applaud Ingo for stepping up and trying to find a middle ground.
Impressive ascii-diagram too :)
> SaxPortlet has specific knowledge about the portlet container's
> implementation of the response. Now the portlet container's
> ResponseImpl
> can provide additional methods such as "getContentHandler()" and the
> specific implementation of SaxPortlet can savely cast the
> PortletResponse
> to ResponseImpl and make use of these additional methods
> ("<~~~~"). We
> consider this a safe break of the Portlet API contract.
Am I right to say that the PortletResponse interface still does not have a
getContentHandler() method.
Will the abstract class SAXPortlet have any dependencies on XML?
What will the SAXPortlet interface (abstract class) look like?
Let me ask clearly: are you proposing any dependencies on the XML classes?
I could be wrong, but it doesn't appear to me that the API is embracing the
SAX approach.
The part about casting and breaking the Portlet API contract doesn't seem
right. I guess that's the nature of compromises...
I do like the abstract SaxPortlet adapting SAX events and then writing to
the servlet stream. This makes sense.
After reading Thomas's comments, I understand that standardized Java APIs do
not depend on other Java APIs.
Ive searched through quite a few java apis looking for a precedence, but I
couldn't find one such dependency.
I also found something in the Servlet 2.3 spec, but I don't know what to
make of it yet.
The spec. suggests servlet 'filters' for XSL transformations.
- david
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
