Hi,
I'm meanwhile convinced, that this discussion won't lead to a consensus, if
each of us keeps defending his view on a technical level. However, I really
like to find a compromise that everybody can agree on. On a meta level of
this discussion, I can see the point that it would hurt the "SAX advocates"
more, if there is no way of producing direct SAX output, than it'd be the
other way round. That's why we where trying to find a way of integrating
the SAX requirements, without integrating the additional methods. I think
we have found a good way that might be acceptable for all of us. :-)
The basic idea is that the Portlet API defines the interfaces and default
implementations of abstract portlet classes (that are subclassed by the
actual portlets). A certain portlet container implementation could replace
these default implementations and make use of extensions that are specific
to this portlet container implementation:
(Note: The following picture is best viewed with a fixed width font, e.g.
"Courier New")
Portlet Container API Portlets
_
| |
v---. | | v---.
PortletRequest | I |-----|-|-------------->| |
'---' | | | |
| | | I | Portlet ( 1 )
v---. | | | |
PortletResponse | I |<----|-|---------------| |
'---' | | '---'
| | | ______|______
| | | | |
| | | | |
^ | | ^ ^
,---. | | v---. v---.
ResponseImpl | C |<~~~~|~|~~~~~~~ |AC | |AC | ( 2 )
'---' | | '---' '---'
| | SaxPortlet StreamPortlet
| | | |
| | | |
| | ^ ^
| | ,---. ,---.
| | | C | | C | ( 3 )
| | '---' '---'
|_| aSaxPortlet aStreamPortlet
Level (1) contains interfaces defined by the API.
Level (2) are classes and abstract classes that implement these interfaces.
On the portlet side, these implementations are part of the Portal API,
however, it is the portlet container's choice whether to use these
implementations or to replace them. (All classes and interfaces checked
with "v" are part of the portlet_api.jar, so to speak).
If a portlet container does replace the abstract class SaxPortlet, then
SaxPortlet has specific knowledge about the portlet container's
implementation of the response. Now the portlet container's ResponseImpl
can provide additional methods such as "getContentHandler()" and the
specific implementation of SaxPortlet can savely cast the PortletResponse
to ResponseImpl and make use of these additional methods ("<~~~~"). We
consider this a safe break of the Portlet API contract.
Level (3) are actual portlet instances. They extend the abstract portlet
classes of level (2). They will run properly no matter whether the derived
abstract classes are the default implementations or the portlet container's
replacements.
There can be different requirements for the different portlet types, e.g:
A portlet that derives from SaxPortlet would be required to return full
documents, whereas the StreamPortlet is required to return specified markup
fragments. The default implementation of SaxPortlet (and others that may
follow) is to do portlet-level "post-processing" and map the full document
to the fragment as required by the portlet container. We can decide whether
to do so with supplied stylesheets or by wiring the content handler(s)
accordingly.
Does this sound like a reasonable approach?
ingo.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
