I think it is useful to provide a little summary of the current state of
the discussion.
I tried to give a neutral summary on each item, followed by my opinion.
Point 1: Should JetSpeed require portlets to produce full documents ?
Producing full documents means that the portal implementations would need
to decide which parts of complete documents returned by portlets should
actually be embedded in the overall page created by the portal.
The motivation behind this - as Raphael described it - is that there are no
guidelines defined for fragments that should be returned by portlets for
markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the guideline
for portlet developers should be "Portlets must output well-formed
(complete) documents conforming to the DTDs required by the client devices"
instead of "Portlets should return well-formed document fragments suitable
for aggregation in well formed documents conforming to the DTDs required by
the client devices".
The result of JetSpeed requiring portlets to produce full documents would
be that all content generated by portlets would need to be post-processed
by the portal implementation. There seems to be agreement that this
introduces significant performance and memory overhead compared to portlets
directly writing fragments to the portlet output stream without
post-processing. There is disagreement on whether the resulting performance
and memory overhead is acceptable or not.
(My Opinion (TS): We have implemented a portal that serves HTML, WML,
VoiceXML and cHTML. The portlets directly write mark-up fragments to the
output stream using JSPs or Stylesheets without post-processing, which is
very fast. Forcing all content to be post processed through a SAX parser
would impose an unacceptable performance degradation on our portal. We can
make guidelines for content fragments that should be created by portlets
available to resolve the issue of missing guidelines.
My opinion is that we should under no circumstances require complete
documents to be returned by portlets, as this woud introduce an inherent
limitation of JetSpeed's performance.)
Point 2: Should the Portlet API provide dedicated methods for SAX output ?
This means that the methods getContentHandler() and getLexicalHandler()
would be added to the PortletResponse interface.
The motivation behind this is that it should be possible for portlets to
output SAX events rather than writing to the output stream so that portal
implementations that internally process SAX events can provide document
handlers that would directly be invoked by portlets rather than parsing the
portlet response's output stream to create SAX events.
The result of the JetSpeed Portlet API defining the SAX specific methods as
part of the core API would be that the Portlet API depends on the
org.xml.sax package (JAXP). The SAX specific methods are unlikely to be
accepted as part of a prospective Portlet API standard. Adding the SAX
methods would de-facto separate portlets into two kinds - portlets writing
to the output stream and portlets sending SAX events. Portal
implementations would have to be able to run both kinds of portlets, a
stream based portal implementation would need to provide an impementation
of PortletResponse that receives the SAX events from "SAX Portlets" and
writes the content to the output stream, a SAX based portal implementation
would need to parse the content written to the portlet's output stream by
"Stream Portlets" to create appropriate SAX events. This seems technically
feasible, but there is disagreement on whether the SAX methods are
appropriate for a standard Portlet API or not.
(My Opinion (TS): Although it seems technically feasible, we should not add
the SAX methods to the Portlet API. The Portlet API should be designed as a
standard API like the Servlet API, and like the Servlet API it should not
contain specific methods dedicated to specific methods of creating output,
be it SAX, DOM, ...)
Best regards,
Thomas
Thomas Schaeck
Portal Architect
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
