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]
