I haven't had much feedback on the proposed compromise but after a private
discussion with Raphal I think that some more detailed description will be
helpful. Furthermore, even though my proposal allowed to use both
approaches (portlets delivering output streams to the container as well as
portlets delivering sax events to the container) it still stressed in some
way, that the stream based approach would be the basic, standard way,
whereas the sax event way was only an extension. (And meanwhile, since I
didn't finish this mail yesterday, Raphael send an proposal that exactly
inverts this emphasis :) )
I try to refine my proposal so that both alternatives (and even additional
ones) are all totally equal.
--> §I All portlet types are equal! ;-)
Ok, the idea is now following: In order to not induce an emphasis on either
Portlet type,
* for each portlet type, there is a extra package, containing at least one
abstract class that implements the portlet interface.
* for each portlet type, there is a subinterface of PortletResponse that is
specialized for the needs of the respective portlet type. E.g.:
- SaxPortletResponse has methods getLexicalHandler(), getContentHandler()
- StreamPortletResponse has the method getWriter()
The abstract classes cast the PortletResponst object in their service
method to the respective PortletResponse objects.
* The interface PortletResponse itself doesn't provide _any_ methods for
returning content.
* Theoretically, there could be other portlet types besides SaxPortlet and
SteamPortlet, e.g. "DomPortlet, EcsPortlet, HtmlPortlet"
(Again: The following picture is best viewed with a fixed width font, e.g.
"Courier New")
Portlet Container API Portlets
_
| |
A---. | | A---.
PortletRequest | I |---|-|---------------->| |
'---' | | | |
| | | I | Portlet
A---. | | | |
PortletResponse | I |<--|-|-----------------| |
'---' | | '---'
| | | ____________|____________
| | | | | |
^ | | | | |
A---. | | ^ ^ ^
StreamP.Response A---.| | | AC--. AC--. AC--.
SaxP.Response A---.|' | | |AC | |AC | |AC |
XYP.Response | I |' | | '---' '---' '---'
'---' | |
| | | SaxPortlet StreamPortlet XYPortlet
^ | | | | |
C---. | | | | |
Response C---.| | | ^ ^ ^
Impl.s C---.|' | | U---. U---. U---.
| C |' | | | C | | C | | C |
'---' | | '---' '---' '---'
|_| aSaxPortlet aStreamPortlet aXYPortlet
I checked the boxes:
(A) provided by the Portlet API
(C) provided by the Portlet Container
(AC) provided by the API but can be replaced by the container
(U) classes implemented by the potlet developer
The above approach has following advantages:
* There is really no "default, standard" way, we won't have to decide
whether the sreaming way or the sax way is reflected already in the root
PortletResponse.
* We can specify different constraints for different portlet types:
SaxPortlets return full documents, StreamPortlets only fragments. This
makes allowence for different goals per portlet:
- A SaxPortlet tries to achieve a maximum of safty and as its output will
usually be post-processed anyway there is no big additional impact on
performance.
- A StreamPortlet aims to achieve a maximum of performance and as this
forbits post-processing, it has to return only document fragments. (They
have to comply to certain rules).
[Well, in the java docs that I've committed, there is actually no
"StreamPortlet" class, instead there are two abstract classes
"FragmentStreamPortlet" and "FullStreamPortlet". The only difference is the
"full document" vs. "fragment" requirement.]
* A portlet container that supports only certain types of portlets can
check already at the deployment time whether it is able to support a
certain portlet or not.
* Portlet containers could specialize on certain design goals, e.g. safty,
universality, performance...
The main disadvantages:
* The base PortletResponse interface is "naked". A PortletResponse object
doesn't help anything, you always have to cast it. I.e. that there is no
"default way" that the portlet API gurantees to work always and in every
container.
* There can be portlet containers that support only some portlet types.
Portlets do not necessarily run on _every_ portlet container, but only on
those that support their type. (This is compareable to the beginning of
EJBs when not all containers supported entity beans for example).
* A developer can't write a portlet that implements the portlet interface
and extends some other class at the same time. As there is no
multi-inheritence in java, portlets are forced to extend only the abstract
portlet classes.
I updated the java docs in the proposals directory so that everybody can
have a look at them. They are more detailed, but I hope that this mail did
also make the idea clear.
I still owe you a proposal that defines which rules document fragments will
have to comply to in order to by a "well-defined fragments". Didn't get to
it yet, but it'll follow.
I hope that the above is a fair compromise in which all of us should find
their requirements and design goals taken into account. However, for none
of us it will be as neat as we whished it'd be - but that's the nature of
compromises...
Ok, then: comments?
ingo.
P.S.: Raphael suggested to have an IRC chat on Monday or Tuesday evening
(european time). That'll give us the possibility to speed up the discussion
and bring it to an end. I think this is a good idea.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
