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]
