At 08:11 02/15/01, David Sean Taylor wrote:
>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.
I will send a refinement of my proposal today or tomorrow that'll change
some details slightly.
Still I answer your questions in regard to how I meant the proposal already
posted:
>Am I right to say that the PortletResponse interface still does not have a
>getContentHandler() method.
Yes, it doesn't.
>Will the abstract class SAXPortlet have any dependencies on XML?
Yes, it has to handle Sax events...
>What will the SAXPortlet interface (abstract class) look like?
Please wait for the refinement, I'll post java docs - that should make it
clear.
>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.
Not really. If you want to process sax events in the portal engine, then it
doesn't make sense to convert it into a stream in the SaxPortlet and
reparse it on the other side of the portlet in order to convert it back
into sax events.
>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
>
Again, please wait for my refinement, Raphael will post a second proposal
as well. This should give the basis for a following discussion.
ingo.
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
>List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
