Re: [Springframework-rcp-dev] ApplicationWindowAware & commands-context

[Peter De B. <pet...@gm...>]

Jan,

as I said at JavaPolis, I had started implementing something similar, but
I've ran into similar problems that are not easy to solve.

I agree that we should push it to the Spring Desktop project.

regards,

Peter

On 3/16/08, Jan Hoskens <jh...@sc...> wrote:
>
> I stumbled on some problems concerning the CommandManager that is set as
> a bean post processor in the commands-context. It creates a registry of
> commands and configures them when they are created. Normally it would
> create one manager for each window. If I try to have the
> commands-context imported in the application-context, the registry is
> created once and hence some things can go wrong when requesting a
> command from the registry.
>
> Fixing this is quite harsh as it would need a refactoring of the
> CommandManager: extracting the bean post processor, creating the
> commandManager separately for each window, probably having a global
> commandManager as a parent containing the commands not bound to the
> applicationWindow, commands that do have the ApplicationWindowAware
> interface should be inserted in the correct CommandManager ...
>
> This all is too big a change to implement for the release and is one of
> the things that should be taken into account when starting with the
> Spring Desktop project. I do think a workaround is possible by not using
> the ApplicationWindowAware interface outside of the commands-context but
> directly accessing the current window through the Application instance
> and possibly storing it for a short period (to ensure that changing the
> active window in between wouldn't interfere).
>
> I'm going to extract the stuff I had implemented just in case and revert
> my local copy.
>
> Kind Regards,
>
> Jan
>
>
>
> On Fri, 2008-03-14 at 17:37 +0100, Jan Hoskens wrote:
> > Hi all,
> >
> > I'm currently looking at the problems concerning the extra application
> > context for the commands and the associated ApplicationWindowAware
> > interface (relates to issue RCP-376). This is what I've done on my local
> > machine to fix this:
> >
> > 1) Implemented an ApplicationWindowScope. It contains a small registry
> > in map form to store the objects that are scoped 'window' for each
> > ApplicationWindow. It tracks the window by listening to application
> > events so that at the moment the that a bean is requested, it searches
> > its 'registry' for that bean, creates if necessary and stores it. When
> > the ApplicationWindow closes, another event will cause a removal of all
> > stored objects for that window.
> >
> > 2) Refactored the ApplicationWindowSetter to listen to the same events
> > as the scope, thus tracking the window that is active or being created
> > at the moment. This allows the AWS to be used as a normal
> > beanPostProcessor and by declaring it in the context your beans will get
> > the window injected. Mind though that if you use this interface,  the
> > bean needs to be in the 'window' scope as well to manage it's lifecycle
> > correctly.
> >
> > 3) Adapted the launcher to register the scope and its listener.
> >
> > 4) Adapted the lifecycleAdvisor to be able to not use the
> > commands-context set as windowCommandBarDefinitions and handled in a
> > separate context. So just use <import/> instead.
> >
> > 5) WindowManager and AbstractApplicationWindow are sending some extra
> > application events to make this work.
> >
> > Some things to know: I've successfully adapted a small app to use the
> > scope. I did this by using the context import, setting the menu beans in
> > 'window scope' as well as all other beans that implement the
> > ApplicationWindowAware interface. Mind that the whole chain should be in
> > the correct scope: menuBean->subMenuBean->myAppWindowCommand all three
> > need the 'window scope'.
> >
> > I can commit this as an additional way of configuring or I can remove
> > the old way of having a separate application context. Not sure yet what
> > to choose as these changes are quite new and not yet fully tested. I'm
> > going to check the other richclient samples and see if they expose any
> > problem with this approach.
> >
> > If anyone has some remarks or another view on how to implement this,
> > please share your thoughts.
> >
> > Kind Regards,
> > Jan
> >
> >
> >  **** DISCLAIMER ****
> >  http://www.schaubroeck.be/maildisclaimer.htm
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>   **** DISCLAIMER ****
>   http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>