springframework-rcp-dev

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

[Arne L. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25201 ] 

Arne Limburg commented on RCP-165:
----------------------------------

My first patch is included in the second so you may savely delete the Application.java.patch

> 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: Oliver Hutchison
>             Fix For: 0.3.0
>
>         Attachments: Application.java.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 message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

[Jan H. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25231 ] 

Jan Hoskens commented on RCP-165:
---------------------------------

Some remarks:

3) You've bypassed the ApplicationPageFactory by directly creating a DefaultApplicationPage in the openWindow. I think we should let the factory handle the null case.

4) why are you providing a commands-context that will always be overruled and hence unneeded? I can imagine starting a new app from an archetype which does provide something like this, but I don't see why we would include a sample-xml with the rcp-support-jar. Can't we opt to have an empty menu or no menu at all instead? 

Besides this, I would like to refactor the advisor in order to remove these magic bean names so anyone who would like to have menu or/and toolbar can define this with the advisor in a more clear way. This would also allow to reuse menu's in other apps (think of suites or so).

WDYT?

Thanks for the patch!

> 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
>
>
> 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 message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

[Arne L. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25262 ] 

Arne Limburg commented on RCP-165:
----------------------------------

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.

> 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 message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

[Rogan D. <ro...@da...>]

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

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

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

[Jan H. (JIRA) <no...@at...>]

    [ 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 message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

[Arne L. <A.L...@ad...>]

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.
> 
> 

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

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

[Arne L. <A.L...@ad...>]

Hi Jan,

I knew about the postprocessor, but I didn't think about multiple 
windows. So one solutionis the the special beanfactory, but what about 
declaring all commands as prototypes in the same beanfactory as the 
advisor. The ApplicationWindowPostprocessor could check this constraint 
and throw an Exception otherwise. We then could inject the toolBar and 
menuBar into the command-manager (this can also be done in the current 
configuration) and looking for the command-manager by type in the 
advisor. Then no special bean name is needed, no special beanfactory for 
commands and we can have multiple windows with multiple commands.

Kind regards,
Arne

Jan Hoskens schrieb:
> 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
> 
> -------------------------------------------------------------------------
> 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
> 

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

[Arne L. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25357 ] 

Arne Limburg commented on RCP-165:
----------------------------------

Besides the issue to remove the commands-context.xml completely from the advisor, I would like to have a nice default for the menubar and toolbar. But I see that my default-commands-context.xml does no good step in that direction. What about a DefaultMenuBarCommandGroup that is created in getMenuBarCommandGroup if no commands-context is set or if the menuBarBeanName is not set. Same could go with the toolBar. We then could remove your magic bean names. I will create a patch with an empty CommandGroup in that case. If you agree, I would implement the DefaultMenuBarCommandGroup and DefaultToolBarCommandGroup.

> 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 message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

[Arne L. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25999 ] 

Arne Limburg commented on RCP-165:
----------------------------------

Are you still not happy with my patch?

> 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, 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 message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

[Jan H. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_26014 ] 

Jan Hoskens commented on RCP-165:
---------------------------------

I'm sorry, I was involved in other stuff lately. Thanks for the poking though, I've scheduled some rcp time this afternoon and will review your latest patch.

> 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, 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 message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira