Jon,
the intent of this Portlet API is not only to be used in JetSpeed, we
envision this API to evolve into a standard.
The goal is to achieve interoperability between portlets and portlet
containers like the Servlet API provides interoperability between servlets
and servlet containers. For this reason, the API must be independent of any
implementation details, be it Turbine or JetSpeed. Consequently, we defined
interfaces for logging, action processing and hopefully everything else
that is relevant. Next steps need to be a specification that describes the
contracts between portlets and portlet containers and the definition of
Portlet Archive (PAR) files.
JetSpeed and Turbine are one particular portlet container implementation
that might become the reference implementation for a standard Portlet API.
Given this background information, you might want to reconsider your vote.
Of course JetSpeed's implementation of the Portlet API should use Turbine
wherever appropriate.
Best regards,
Thomas
Thomas Schaeck
Portal Architect
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
on 2/2/01 4:50 AM, "Thomas F. Boehme" <[EMAIL PROTECTED]> wrote:
> 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.
ahhh...I see (ignore my email about why checking in javadoc is bad), why
didn't you also check in the code?
> 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.
Why aren't you just using Turbine's action processing? I don't see a need
to
abstract this at all.
> 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.
-1. Use Turbine's Logging mechanism. This has been recently completely
revamped and is *excellent* now as it is backed by Log4J.
thanks,
-jon
--
Honk if you love peace and quiet.
--
--------------------------------------------------------------
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]
