Santiago Gala wrote:
> Do you mean that javax.servlet.* is more standard than javax.xml.* (Trax
and Jaxp)?
What I am trying to point out is that it is not good for a standard Java
API depend on other Java APIs that are not part of the JDK classes.
If you look at javax.servlet for example, it has no dependencies on any
other Java extension, only on classes and interfaces in the JDK classes.
Whenever possible, dependencies of Java APIs to classes/interfaces that are
not JDK classes should be avoided.
> 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.
Writing to the response stream just seems like the natural way of
outputting content to me - and probably to many people used to write
servlets. I think this is different than using SAX, DOM, or ECS.
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
Santiago Gala <[EMAIL PROTECTED]> on 02/14/2001 03:56:45 AM
Please respond to "JetSpeed" <[EMAIL PROTECTED]>
To: JetSpeed <[EMAIL PROTECTED]>
cc:
Subject: Re: [vote] Portlet API
[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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
