[EMAIL PROTECTED] wrote:
>
>
> 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.
>
That depends on the use. I agree that imposing this requirement is not right.
The decision to postprocess should be up to the implementor.
> (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.)
>
I agree that postprocessing should not be mandatory. But if we don't have event
processing
in the API it is not optional, but nearly impossible.
There is an activity for the specification of XML fragments (XHTML, WML, VoiceML, ...).
http://www.xmlhack.com/read.php?item=1067 describes it. (Taken from Jetspeed xmlhack
channel).
To me, the requirement of outputting documents looks too strong, and short term
sighted.
There is ongoing effort to specify how to describe valid XML fragments, and the trend
is
to have markup languages that follow a schema/DTD (XML).
>
> 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.
>
It could be done with other methods, possibly using only javax.xml.transform.* classes.
> 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.
>
It will allow the following things:
- More modular design of a portal, as portlets can output abstract markup, that is
transformed
to the target device. So one portlet implementation gives output for several devices.
- Integration (both of portlets and of the portal container as a whole) with XML tools,
that accept already this input, or output, without performance penalties.
- If portlets are written to a given DTD, the portal can serve different Content Types
from the same content.
Now we are doing this with RSS content, for instance.
> 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
??? why not? javax.xml.* is already part of the J2EE. Who will not accept them?
> methods would de-facto separate portlets into two kinds - portlets writing
This is precisely what I'm trying to avoid. If the Portlet API does not
accept XML events, someone will write a Content Aggregation API for XML.
I am trying to get OUR API good enough for every use, or at least interoperable
with XML code.
> 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
??? When Websphere, iPlanet, Oracle, ... all make heavy use of XML and transformations,
why is it that difficult? I can't see.
> 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, ...)
>
Do you mean that javax.servlet.* is more standard than javax.xml.* (Trax and Jaxp)?
Maybe it is true, but I can't see it.
The servlet API contains a specific method of creating output, namely
writing to a response stream.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
