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

[Jan H. <jh...@sc...>]

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