Raphaël Luta wrote:
> Following the discussions on the Portlet API, there's no strong consensus
> on the following points of the Portlet API and so they should be voted
> upon.
>
> For those who did not follow the arguments, pleae read the "Secure
> Portlets"
> thread in the mail archive before voting.
According to the voting rules, -1 is blocking, blah blah... This scares
me, as I would strongly like to have a consensus proposal.
So, we should refine more the questions. I will not vote yet.
I will explain once more why I need these calls:
Our templating system is composed of XSLTStylesheets. There are (or
could be) portlet level templates, but there are also global templates
(layout, page, navigation, soon template...). With the current proposal,
our "child" portlets will have to handle their output to a new layout
system to avoid expensive reparsing of the output of each portlet when
the "layout" processing is done. With the proposal of
getContentHandler(), we can send this output straight into the template
stylesheet. This is similar to what Turbine does now: allowing the use
of the response writer or outputting ECS objects. With the portlet
proposal as is, we would have to reparse the output of each portlet and
regenerate events to process our templates.
If we don't get through this extension, our implementation will have to
extend this API to achieve efficiency, and we will be, effectively,
creating a new de facto API for our implementation. Our proposal will
enable our portlets running in standard engines, while they would be
more efficient in XML aware environments. We would be doing "embrace and
extend" with the portlet API, and I don't want this to happen.
On the other hand, with Raphaël's solution, if you reuse a (one of my)
XSLTPortlet in a jsp or velocity based implementation, all you have to
do is to plug the "SAXStreamer" as ContentHandler of my XSLTPortlet and
serialize there. As my portlet would not have donoe this effort, there
is no redundant work. If your portlet container is XML aware, it could
be processed in a different way, while if not, it will be streamed as it
is evaluated.
I agree that DOM (maybe ECS) could be asked for. But we already said
that DOM can be turned into SAX very easily, and proper ECS also. Thus
once you have the basic additions to the API, DOMPortlet and ECSPortlet
are simple to implement using this API. (Note: if you use a
StringElement of ECS to embed markup, this will not work. But this is
dirty anyway)
>
> Point 1:
> Should the Portlet API mandate that portlet only output full documents
> rather
> than document fragments ?
You mean here "proper" markup? This is more radical thant point 2. And
impossible to enforce unless getWriter() disappears or expensive parsing
is done with each portlet output. Even for our current SAX model,
portlets otput documents that are acceptable as parts of the "global"
page DTD. For instance <portlet>...</portlet> This is a document on its
own, but is also part of the document that composes the page as a whole.
Thus, for us this will be true. But I wonder if it can be true for
everybody. Even for us, in some cases HTML fragments are bundled as
CDATA (this will not work with WML) and passed through. We are trying to
get rid of this, but it will not be easy until when most sites generate
XHTML.
>
> Point 2:
> Should we add a getContentHandler() and getLexicalHandler() in the
> PortletResponse interface ?
> A portlet will not be able to use both getWriter() and
> getContentHandler()
> in the same request response.
I need these calls to avoid expensive processing, so my vote is obvious
(although I will not vote formally until the issues are clearer). :)
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
