At 22:35 12/02/2001 -0800, you wrote:
>Ive been reading this thread with interest. I have some comments, questions
>and suggestions:
>
>Point #1 - Portlet API mandate that portlets only output full documents
>rather than document fragments:
>
>- There is some confusion WRT portlets producing document fragments vs full
>documents.
> AFAIK, this is a new concept to Jetspeed, with the exception of Ingo
>Rammer's WebPagePortlet.
> This seems to be a complicated process. How would one go about defining
>the translation of, for ex., a <BODY> tag to a <DIV> tag.
> How do you go about specifying which tags are discarded?
> Saying that, after some consideration, it does makes sense. When creating
>portlets, Im often stripping away the headers of HTML.
> Then there is the issue of merging JavaScript and CSS, namespace
>conflicts.
> Do you plan on addressing these issues?
> As for performance, yes it will be slower, but would we be applying this
>post-processing with every request?
> The implementations would be smart enough to do some kind of caching of
>documents.
> I hope Raphael can give us some details of the motivation...
The motivation is that I can't think of good output guidelines for the main
target
markups ((X)HTML, WML, SMIL, VoxML, FO) that will be the obvious choices
for all portal implementations.
Also I'd rather write an API that specifies:
"Portlets output must be well-formed document. The must be valid for the DTDs
supported by the portal implementation"
rather than:
"If your portlet produces HTML, should wrap all your markup in a <table>
element,
if your portlet produces WML, you should produce a sequence of <card> elements
but can't use <templates>, etc....."
See what I mean ? ;/
> Is it possible to support both fragments and full documents?
> Isn't this something that could be configured in the Portlet Configuration
> - PostProcessing=false
That would not answer the main issue (delievring fragments working for all
implementations) but could allow portlet writers to write "dirty" portlets
taylored for one implementation and thus achieve maximal performance
for this implementation.
Definitely something to consider.
>Point #2 - add getContentHandler(), getLexicalHandler() to PortletResponse
>interface:
>
> Implementors who do not use SAX will be required to implement these
>methods (in a abstract base class that does nothing).
The implementation is trivial, just serialize all the events to a byte stream.
> What is the problem with having a dependency on SAX (JAXP)?
None that I'm aware of.
--
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]
