Re: [Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

If I've examined the advisor correctly, the only reason that the
commands are defined elsewhere is that they are processed by a specific
CommandBarApplicationContext that registers a special beanPostProcessor
ApplicationWindowSetter. The latter one will install the newly created
window on the command if it's implementing ApplicationWindowAware. (eg
ShowViewCommand is such a command)

If we can fix this, a separate context isn't needed anymore. All
commands could then just be in the regular context by importing the xml
instead of injecting the url in the advisor. Haven't gone deep enough to
provide a solution for this though. 

One question just kinda dropped into mind: is it possible to define an
ApplicationWindow scope in spring? So every bean(command) that needs to
be applicationWindowAware will be instantiated based on that scope?

I'm not (yet) into the OSGi details, so I'm not aware of all the
possibilities on that end.

Kind Regards,
Jan


On Tue, 2007-08-07 at 23:25 +0200, Rogan Dawes wrote:
> Arne Limburg (JIRA) wrote:
> > 
> > 3) You are right. I have upgraded my patch.
> > 
> > 4) It is great for prototypes.
> > 
> > I don't think you have to refactor the advisor. These bean names are
> > not magic anyway. You can change them via the menubarBeanName and
> > toolbarBeanName properties in DefaultApplicationLifecycleAdvisor.
> > With this you can also change the toolbar without the need of
> > specifying any menubar. You only need to include my
> > commands-context.xml into yours, provide your own toolbar-bean and
> > set its name in the advisor. You can also add new menubar entries by
> > specifying a new menubar bean, but reuse the fileMenu, editMenu,
> > windowMenu and helpMenu.
> > 
> > But anyway this cannot be the final solution. We need a more
> > pluggable architecture for the commands context. What about a special
> > menubar bean that acts as a beanpostprocessor to search for menubar
> > entries? We then would need only a marker interface like MenubarEntry
> > for the commands that should be plugged into the menubar. Same could
> > go for the toolbar and the new-menu. You then would just have to
> > specify your additional menus, new-commands and toolbar commands and
> > could use the default-commands-context for the rest. We then should
> > provide the ability to specify multiple commands-contexts in the
> > advisor.
> 
> Hi folks,
> 
> I have been considering what would be required in order to enable OSGi 
> and Spring RCP to interoperate. The basic approach would be to provide 
> the application "shell", with a number of plug points, and allow OSGi 
> providers to register things like views/view descriptors, 
> commands/command descriptors, etc.
> 
> The thing that would need to change a fair amount is the 
> commands-context.xml that we have currently. At the moment, each 
> application window creates a whole new context by reading 
> commands-context.xml. This means that setting beans to be singletons, 
> etc is ineffective, since the bean is only a singleton *within that 
> context*, and the context is sourced anew for each application window.
> 
> One approach might be to introduce CommandDescriptors, from which 
> instances of the described Command are created, similarly to the 
> ViewDescriptors. This would allow OSGi plugins to register a 
> CommandDescriptor in the appropriate place, and this would still work 
> for multiple app windows.
> 
> Any comments? Am I overcomplicating things?
> 
> Rogan
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm