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

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

There is already a postprocessor that does this. But additionally the
commands are processed by a different beanfactory as well (on which the
postprocessor is installed). The commands that are
ApplicationWindowAware need to be initialized per window. So when
opening, the commands-context is created, AppWindowAware commands are
postprocessed. Then when you open a new window (eg through the new
window command that is provided) the advisor will create a new
commands-context and all commmands are initialized anew. This ensures
that per window the AppWindowAware commands will receive the correct
window.

Say that you have a command that will provide a new view in your window,
then that will probably have a reference to its AppWindow. When opening
a new window, that command needs to be recreated and injected with the
new window to work on.

Kind Regards,
Jan

On Sat, 2007-08-11 at 10:53 +0200, Arne Limburg wrote:
> Hi Jan,
> 
> what is the problem with the ApplicationWindowAware-ness? Couldn't the 
> lifecycle-advisor act as a bean-postprocessor to inject the application 
> window to all ApplicationWindowAware beans? The only thing we would have 
> to do is to open the window during the initialization of the 
> lifecycle-advisor or the application. I have had a short try on this. I 
> moved the application.start() code into afterPropertiesSet() of 
> Application. Everything worked fine. setOpeningWindow of 
> ApplicationLifecycleAdvisor was called before afterPropertiesSet() of a 
> command that I defined in the application-context. Is there another problem?
> 
> Regards,
> Arne
> 
> Jan Hoskens (JIRA) schrieb:
> >     [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25315 ] 
> > 
> > Jan Hoskens commented on RCP-165:
> > ---------------------------------
> > 
> > 3) thanks
> > 
> > 4) as I mentioned, it can be used for prototyping or new projects if we provide it in the archetype. You start off by creating a new project (mvn archetype stuff) and then you get a structure to start from which includes a basic project-rcp.xml and commands.xml (like the one you provided). All your cases would then apply to that setup. I still don't think we need this in the support jar.
> > 
> > As for the beanNames, I call them magic because you don't need to inject them. There's no other connection between the advisor and the menuBeanId than in code. I would prefer to remove the in-code defaultIds and let them be injected in the code. This is more transparant in my opinion.
> > 
> > Concerning the last remark: I think commands should be reusable anywhere, as is the case now. You shouldn't need to define if it may end up in the menu/toolbar etc... It's just another component to represent the same command. The only issue that is surfacing here is the separate commands context. It would be better to just have the commands added to the context (or preferably by importing the current commands.xml instead of providing the url to the advisor for special handling). The problem here is that there should be a way to fix the ApplicationWindowAware-ness of the commands, which is why there is a separate handling currently. Not yet sure how to do this, but I've posted this issue on the dev list as well to discuss it with the other developers.
> > 
> > 
> >>Eliminate need for special bean names when configuring Application and ApplicationServices
> >>------------------------------------------------------------------------------------------
> >>
> >>                Key: RCP-165
> >>                URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
> >>            Project: Spring Framework Rich Client Project
> >>         Issue Type: Improvement
> >>           Reporter: Oliver Hutchison
> >>           Assignee: Jan Hoskens
> >>            Fix For: 0.3.0
> >>
> >>        Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch
> >>
> >>
> >>We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.
> > 
> > 
> 
> 
> -------------------------------------------------------------------------
> 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