|
From: Peter De B. <pet...@gm...> - 2008-03-17 06:17:22
|
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 > |