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!
Cheers,
Thomas
----- Original Message -----
From: "David Sean Taylor" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Tuesday, February 13, 2001 7:35
Subject: RE: [vote] Portlet API
> 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...
>
> Is it possible to support both fragments and full documents?
> Isn't this something that could be configured in the Portlet
Configuration
> - PostProcessing=false
>
>
> 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).
>
> What is the problem with having a dependency on SAX (JAXP)?
>
> Im trying to find some parallels here, how this kind of duality of
> interfaces has been handled in other designs.
> Im thinking of some kind of adapter for SAX, assuming that streams are
> the standard.
>
>
> -- david
>
>
>
>
> --
> --------------------------------------------------------------
> 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]
