At 18:57 02.07.2004, you wrote:
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
Ok sorry about that I didn't express myself correctly. I don't have a problem with J2 relying on PortletWindows. The problem is that currently PortletWindows are strongly tied to Fragments, which makes the NavState component depend on Fragments too, and less standalone. If it relies on PortletWindows only, and provided a way to dynamically associate PortletWindows with any ObjectID, then it could be associated to anything (which would solve my problem :)).
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)1:1 was all I got around to implementing
No problem, I was just talking about the future :) I'm willing to help as much as I can anyway.
The Pluto design supports 1:many, see PortletEntity interface, it has a getPortletWindowList() method
Yes I noticed that.
Regards, Serge Huber.
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
