Menu
▾
▴
springframework-rcp-dev
|
From: Jan H. <jh...@sc...> - 2008-03-14 16:37:41
|
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 |
|
From: Jan H. <jh...@sc...> - 2008-03-16 09:51:22
|
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 |
|
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 > |
Thanks for helping keep SourceForge clean.
X