Raphael,
I agree that it would be a complete waste of resources if all the portlet
does is providing the SAX/DOM interface and streaming it. But I am not
saying that. The idea is that such a derived portlet does everything
required/desired on post-processing the events and only then streaming it.
It's just that it is not the portal itself dealing with the events, but a
special portlet. And the best is: this portlet would run on *any*
implementation of a portlet container. I imagine something like this:
Portlet
-- getPrintWriter
|-- SAXlet (c)
| -- getContentHandler
| -- getLexicalHandler
|-- DOMet
| -- getDocumentNode
|-- ECSlet
| -- getBaseElement
|-- ????
I do think there is a certain elegance in this approach.... If you want I
can prepare Javadoc for this.
As you probably know, you can (almost) always map higher levels to lower
levels but (virtually) never lower levels to higher levels. That's why the
byte stream ultimately has to be the implementation. I am glad you agree to
that.
For the SAX case, I don't think it is a matter of adding one or two methods
to the PortletResponse. That's why I am reluctant to make the mods just yet.
How do we specifiy the stylesheet(s) to be used (if any)? How do we supply
new parsers (if any)? How do we make sure that tomorrow we don't need to add
support for DOM or ECS? If we support SAX, we should probably give the
latter two a chance too. But add support for each of them in
PortletResponse? I don't think that's a good idea.
I still don't see where Jetspeed parses portlet output. And I continue to
disagree with your 80% statement. What assumptions are you talking about for
WML? To some extent every portlet has to make assumptions about controls and
controllers, because every portlet only delivers markup fragments which need
to be (and hopefully are) completed by controls and controllers. But I guess
that's not what you mean....
If you (and Santiago) are still not convinced by the above solution, I
suggest we do a vote on this particular issue. As I wrote before, I am happy
to add those methods if for a good reason -- and a majority on the mailing
list *is* a good reason.
Cheers,
Thomas B.
----- Original Message -----
From: "Raphaël Luta" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Sunday, February 11, 2001 14:33
Subject: Re: Secure Portlets
"Thomas F. Boehme" wrote:
>
> Santiago, Raphael,
>
> What's wrong with doing the things you suggested in a derived portlet?
> Because the stream is the final result you can map (virtually) any other
> method like SAX, DOM, ECS, etc to the stream. This way the interface is
not
> complicated any further, and portlet container writers are not burdened
with
> several implementation paths.
> Also, doing this in derived portlets, mean we can easily add other
mechanism
> including Cocoon2 (so I think), without any modifications to the API!
Sounds
> very appealing to me....
>
Doing this with a derived portlet is a big performance hit for
implementations
that would process natively SAX events (for example Cocoon) because you
would
have a event -> byte streem -> event serialization/parse process which is a
complete waste of resources.
In any case, the dual implementation paths is very easy to deal with since
you
just have to convert the stream you don't want to deal with into the stream
you're intersted (that means either parsing the byte stream or serializing
the
event stream).
Jetspeed 1.3 implementation will certainly use the byte stream path because
it's a natural fit with Turbine and Velocity but if I ever want to write an
alternate implementation, I don't want to be constrained by the API just
because it was optimized for one specific implementation.
>
> I disagree with your assumption that 80% of the portlet markup needs to
> parsed anyway. If that were so something is fundementally wrong. At any
> rate, Jetspeed 1.3a1 does not parse any of its generated markup for
whatever
> reason, and it does what it is supposed to do.
>
My assumption is that for about 80% of the requests, the portal will need
to post-process the portlets output.
Jetspeed 1.3a1 does post-process the markup but is very poor at providing a
stable
portlet environment: any portlet can competely screw the entire portal page
and I don't even speak about WML support where the portlets need to make
assumptions on the controls/controllers used in order to provide valid
markup.
Don't tell me this is good, reliable and solid design.
I don't understand what really bothers you in adding the additional methods
in
the PortletResponse :
- the additionnal implementation constraints are minimal
- it does not influence the performance of native byte stream
implementations
- it broadens the scope of the API since it makes it more efficient on some
possible platforms
So what's the issue ?
--
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]
