On Jul 2, 2004, at 2:41 AM, Serge Huber wrote:
Sorry guys I've been terribly busy trying to save a client from a disaster they managed to create themselves :)
Anyway about the createWindow call, it is something I suggested because I was using J2's PortletWindows to manage nav state for me. I was trying to avoid having to use fragments that don't exist outside of J2 and it seemed like a good solution.
Now this is a question of how we manage these APIs : should they be deleted or should they be part of a "library API" for J2 ? As David mentioned some APIs are also used by Fusion, so removing methods might break J1, and that is not something that we would like.
On another side, freezing APIs should only be done I think on "major" releases, so I'm open to options. I will still have the problem of managing somehow navigation state, and J2's current implementation relies solely on PortletWindow objects.
Portlet Windows are a core concept of a portal. They are part of the portal model and even defined in the portlet specification.
Therefore I don't see an issue J2 relying on the PortletWindow interface
1:1 was all I got around to implementing
Another thing that I'm interesting in helping out with is mapping from window to entity. For the moment we use a 1-1 mapping and this is probably why we don't need some of these APIs. Once we move to a n-1 mapping, we will need to have methods to create windows on existing entities. I am currently doing this in Jahia, where I use n-1 mapping from PortletWindows to PortletEntities (hence the need for the createPortlet(windowID, PortletEntity)
The Pluto design supports 1:many, see PortletEntity interface, it has a getPortletWindowList() method
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
