Re: [J2] Unused methods in PortletWindowAccessor

[Serge Huber]

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.

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)

Regards,
  Serge Huber.
At 20:41 01.07.2004, you wrote:
On Jul 1, 2004, at 11:02 AM, Scott T Weaver wrote:
On Thu, 2004-07-01 at 12:07, David Sean Taylor wrote:
On Jul 1, 2004, at 8:35 AM, Scott T Weaver wrote:
PortletWindowAccessor has 2 methods: createPortletWindow methods that
are never used anywhere, looks like the getWindow methods take care of
this for us automatically.  I propose we delete these unused methods as
they can cause confusion on how the API is used.
-1
I think you need to do a CVS update now and then and be considerate of
I update every day.  I don't use J1 so I don't have it in my
environment, I guess that is on more thing I need to be concerned
about.
what other developers on the TEAM are doing
That is why I asked.  I could have just deleted them.
Yup, you can do whatever you please, but it doesn't change the fact that 
you would have still broken the J1 build.

In my mind, the Jetspeed-1 and Jetspeed-2 teams are the same.
There are two different CVS modules, yet we as committers are members of 
both CVS modules.

Once we have a release, any release of J2, then J1 will become dependent 
on it.
Until then, IMO we do have to be concerned about J1 making use of the J2 API.
So whenever the Jetspeed API changes, compile J1


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
- -- --- -----=[ 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]