Man, this discussion gets going now.... :-0
Santiago, Raphael,
You keep referencing the "simple implementation" of the SAX handler, but I
am sorry guys: you are not drawing the complete picture here. And while you
do so, I would suggest everybody stays away from voting on this issue.
Let me give you an example:
Assume a portlet that generates HTML output (fragment or whole, it doesn't
matter). Part of the HTML is a URL which needs to be resolved against the
portal.
Now case a) the portlet uses streams. The output is generated straight into
the output stream of the portlet response. The URL is generated by Portlet
URI (because that's what it is for). So, the URL is already properly
inserted into the stream. No need for post-processing here. (Except if the
document is a complete one, we need to strip it - I'll cover that topic down
below).
Consider case b) where the portlet uses SAX events. It would call the
appropriate methods on ContentHandler. The URL would be given as is. The
ContentHandler implementation takes the event, processes them and puts them
into the output stream.
THING IS: a "simple implementation" just dumps everything into the stream.
No processing here, in particular, the URL is left alone which means *wrong*
output is generated. So, it's not that simple.
But wait, you'll be saying to yourself "hey, that's unfair, because the URI
could be generated using Portlet URI in the SAX case as well as in the
stream case. True! But the whole point of the SAX event story was, to enable
post-processing.
I think I understand now, Raphael, where your "80%" assumption comes from.
And indeed, if we were to say "Portlet, return a whole document" that would
be the case. But let's face reality (no, not the Jetspeed reality, but
*reality*) - how much content is there generated by XSPs (ie. Cocoon2)? The
majority comes from static or dynamic server pages of one kind or another,
even Velocity does so. Allowing full page document generally as the content
returned from portlets seems completely unacceptable. There may be the odd
content that *is* a full page (eg. coming from a legacy app) but that can be
dealt with an HTML/WML/etc portlet of which a number have been reported on
lately. But the general portlet should return a fragment. And yes, ugly as
it may be, that requires the Portlet API to specify what and what cannot be
returned from a portlet. Well, it is not terribly nice, but not that bad
either.
But again, that means that either SAX events would either require a similar
statement, a "simple implementation" is not possible since the stream
aggregation will not aggregate correct pages, because through the SAX
mechanism complete output would be injected into the otherwise correct page.
Now I will shut up and not comment on this particular topic anymore.
Cheers,
Thomas B.
----- Original Message -----
From: "Santiago Gala" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Tuesday, February 13, 2001 14:14
Subject: Re: [vote] Portlet API
> Thomas F. Boehme wrote:
>
> > David,
> >
> >
> >> Implementors who do not use SAX will be required to implement these
> >> methods (in a abstract base class that does nothing).
> >
> >
> > It's worse than that. A portlet relying on SAX will not work in that
case.
> > That means we have to introduce something that says "I require SAX and
if
> > you don't implement, I am not going to run". Portlet portability adios!
> >
>
> This is not true. I will give you a default implementation that streams
the ContentHandler into the ResponseWriter.
> It is efficient and very simple to implement. This can be the default for
any portal that does not want to have higher
> level processing of SAX events. In fact,
javax.xml.transform.stream.StreamResult already provides such an
implementation.
>
> > Cheers,
> > Thomas
>
>
>
> --
> --------------------------------------------------------------
> 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]
