Folks,
a few minutes ago we (ie. Ingo) posted the javadocs for Portlet API 2. It is
in /proposals department in CVS. All those interested in a common standard
for portlets (hopefully even beyond Jetspeed implementations) are invited to
comment on the API.
I suggest that in about two weeks time we start the voting (unless there are
major disagreements, like incompatabilities to Raphaels new
layout/aggregation system), maybe we can actually agree on core parts
earlier than that (like Portlet, PortletRequest, PortletResponse,
PortletConfig, PortletSession).
Also, the question how we proceed with the implementation. Again, I would
like to suggest a staged approach, focussing on the core functionality first
and introducing the other bits as time permits.
WHAT'S NEW?
Well, a couple of things changed since the last drop (which was before
Christmas). Most importantly, I have introduced an event concept for three
purposes:
o to deliver window handling events (minimize, close, move, etc.) - this is
modeled largley after AWT/Swing
o inter-portlet communication with directed, asynchronous messages.
o portlet-specifc actions attached to urls
Adding additional event categories should be easy. The tricky question has
been where to provide the addListener" methods.
Window and message handling should be well-known concepts, but action
handling may not be that obvioius. The intention here is to enable a portlet
to attach its own actions to a url without having to deal with the url
itself. As soon as a portlet does more than replaying information it found
in other places on the web, you get to a point where the portlets needs
links or buttons in its content. For example, to finish personalizing a
portlet you a "Save" or "Finish" button, or a to-do-list portlet may have an
entry field and an "Add" button at the bottom of the current list to add new
to-dos. Implementing these has been very tricky so far, because the next
screen may be different from the activity you want to perform. The "Save"
button, for example, needs to bring the portlet from PERSONALIZE mode to
DEFAULT mode, but before doing so the portlet needs to save the posted data
which is obviously not the part of the DEFAULT but of the PERSONALIZE mode.
This is where actions come in. The url will be constructed for the
destination mode (DEFAULT in this case), but a SaveAction can be implemented
and attached to the DEFAULT url (whatever it may look like). When the
request comes in from the browser, the action(s) are dealt with first,
before the service() method is called, similar to the way actions and
screens are called in Turbine (thanks Jon for this paradigm). Now, I shall
add that all events (actions, messages, and window) are delivered to the
respective portlet(s) before the service() methods are called. Therefore,
the portlet has a chance to save the posted data before the markup for the
new page is generated.
Going along with window handling, there had to be - of course - a portlet
window which represents the frame and title around the portlet. This is not
necessarily correlated to a concrete object inside the implementation doing
the rendering. It's more of a concept provided to the portlet writer. It
allows you to enquire and set the status of the frame and title around the
portlet.
I also folded the Persistence Service in to the existing concepts, because
personalizing portlets will be essential and a core part of writing
portlets. The service concept should be re-thought, in fact, I believe there
is no need for it in the Portlet API 2 because it defeats the purpose: the
Portlet API 2 enables the very same portlet to run in different portal
implementations (aka portlet containers) and having optional services with
undefined names seems to contradict that promise.
Also new are named sections for the personalization and configuration data.
This allows data to be shared across portlets and portlet instances.
However, it requires the portlet to know the name of the shared section
(there is mechanism to interrogate available names) which is the poor-man's
version of providing a little bit of security in this area. It is by no
means safe. But intelligent implementations (Jetspeed?) may control access
to the shared sections by ACLs attached to those sections. That way, only
authorized user's or portlets may access the shared section.
The log() methods on the context have been morphed into a separate class
(PortletLog) which provides simplistic log levels. I think this should now
be more than enough for that the portlet may log. Plus it's high-level
enough to plug different mechanism underneath.
Making the portlet strictly a single instance (like servlets) has its merits
for non-personalized portlets and for administering the available portlets
in the system. The portlet now follows the Flyweight pattern (see GoF book).
However, for a personalized view of the portlet we need somewhat "virtual
instances" of the single, impersonal portlet object instance. This is
achieved throught portlet session. That's why I call the combination of
portlet instance and session instance the "virtual instance" of the portlet.
Like any real object instance this instance may need to be initialized and
destructed. The corresponding methods are called "beginSession" and
"endSession". At this stage, this is kind of hypothetical. We couldn't
really come up with an obvious scenario but it feels right to so because
otherwise a portlet writer would have no chance whatsoever to initialize the
virtual instance. Your feedback on this "feature" in the Portlet interface
is very much appreciated. Please keep in mind that whatever the Portlet
interface defines has to be implemented by every Portlet unless common
abstract implementations are used. Adding new methods in this interface is
likely to break a lot of portlets in the feature.
Enough of my rambling -- please review the javadocs so that we can get going
with the implementation soon (if I recall correctly the api was supposed to
be implemented before ApacheCon, which I doubt at the moment but staging the
implementation may help us).
Cheers,
Thomas B.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
