I share your preference for using an interface over an implementation.
At the same time it seems to me that the portlet container
implementation should be hidden from me as well.

Up to you to pick between the most benevolent of two evils, but that's
why they pay you the big bucks right?!

Oops, forgot this is Open Source, scratch that thought ;)

-----Original Message-----
From: David Sean Taylor [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 16, 2007 1:12 PM
To: Jetspeed Users List
Subject: Re: Preferences question


On Apr 13, 2007, at 12:40 PM, Melchior, Joris wrote:

> Update on this from my side.
>
> I found that the ContentFragment is not available in an  
> ActionRequest so
> I went looking for an alternative. I found I could use;
>
> RequestContext rContext =
> (RequestContext)request.getAttribute 
> (RequestContext.REQUEST_PORTALENV);
> String portletId = rContext.getActionWindow().getId().toString();
>
> The only niggle I found with it is that it requires the pluto jar file
> for development because the context.getActionWindow() returns a pluto
> PortletWindow. I was wondering if it made sense to change the API at
> some point to return a Jetspeed PortletWindowImpl which implements the
> pluto PortletWindow interface. That way only the Jetspeed API jar file
> is required for development.
>

Well, I prefer to have the dep on Pluto interface than a Jetspeed Impl
But I agree it would be better to only require the Jetspeed API for dev
I will see what I can do there and get back to you







---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to