At 11:39 12/02/2001 +0100, you wrote:
>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.
I understand your point but what you propose is in fact reimplementing
any functionalities already available in a native SAX site manager (like
cocoon 2)
as a portlet so that it can be portable to any container.
That doesn't make sense to me.
>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.
I agree only as far as Jetspeed 1.3 is concerned. I can definitely see other
implementations where the link between portlet and portal is high level and
only converted to low level by the portal at the end of its processing.
>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)?
You don't. Why would a portlet care about this ?
It's a portal implementation job to know what to do with the event stream and
how to process it.
The Portlet API just has to make high-level communication possible between
portal and portet.
>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.
The Portlet API is stream based we'll only consider stream options. It's
trivial
to convert byte streams to string buffers (ECS ConcreteElement is a
specialized buffer) or event streams to object tree (DOM). They're just 2 faces
of the same coin, once you have one you can very easily get the other if
required.
>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....
This is what I mean. In an ideal aggregation system, portlet should not be
aware of
how they'll be aggregated.
For example, rather than simply outputting its HTML content in a <table>
tag, a portlet
can simply output a complete HTML document (with <head> and <body>) and the
portal
can simply strip <head> tags and replace <body> by either a <table> or a <div>.
The same kind of process can be done with other markup languages but it
does require
post-processing of the portlet output.
This is a very important choice:
Should portlets be allowed to output document fragments ?
If so, how can they make sure that these fragments are correctly processed
whatever the
portal implementation they're running on ?
One may want an HTML <table> as root element for the output while the other
will want
a <div>, or talking WML must a portlet output a full <wml> deck, a
<card>, a set of <card>
or simply a <card> content ? This is very important because you can't nest
<card> like you
can nest <table>.
The only way I can see this working across implementations is to mandate
that portlet output
full documents with portal post-processing in order to fit the output in an
aggregated document.
>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.
OK, I think the arguements for both sides have run for long enough, I'll
send a vote request in a
separate mail because some people probably didn't follow our discussions so
far ;)
--
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]
