Raphael,
Please let us clearify your questions a bit more (see my comments below).
At 14:12 02/12/01, Raphaël Luta wrote:
>Following the discussions on the Portlet API, there's no strong consensus
>on the following points of the Portlet API and so they should be voted upon.
>
>For those who did not follow the arguments, pleae read the "Secure Portlets"
>thread in the mail archive before voting.
>
>Point 1:
>Should the Portlet API mandate that portlet only output full documents rather
>than document fragments ?
I don't really get this point. How could portlets output full documents,
doesn't it always have to be a fragment? Or are you thinking in XML
documents that are stripped don to fragments later? Sorry, I really don't
undersand this point.
>Point 2:
>Should we add a getContentHandler() and getLexicalHandler() in the
>PortletResponse interface ?
>A portlet will not be able to use both getWriter() and getContentHandler()
>in the same request response.
I share the demurs of Thomas: Sax and XML is very popular at the moment,
but most general are still streams. I'm not sure if it's wise to open the
door for specialized ways of content passing: What if other "standards"
want their own interface too, what if the Sax interface changes (it did
change often in the past!).
This would really put the stability of out portal API at a risk. The
problem is that once those methods are in the interface and portlets are
programmed against it, we are dammed to support them in the engine if we
don't want to scare the people away from the portlet interface.
The alternative - not quite as nice, but still good - is to do all
processing on the portlet side of the API: A Saxlet could take the XML
output of the SaxPortlets, do all necessary processing, and produce a
markup stream. This is really stupid if you want to postprocess the
aggregated page on the other side of the API, in the portal engine, I agree
with you. Yet, the question for me is: is there really a need for doing so?
So I think Point 2 is better fomulated as:
"Is there a requirement for postprocessing the whole portal page in the
servlet engine after the aggregation (alternativ 1) or is it sufficient to
take the XML and convert it into markup on the portlet side of the API
(alternative 2)?"
With alternative 1 there is the danger of making the portlet API more
complicated and (that's important!) *less stable*.
Is this a fair way of putting it?
ingo.
>--
>Raphaël Luta - [EMAIL PROTECTED]
>Vivendi Universal Networks - Services Manager / Paris
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/[email protected]/>
>List Help?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
