I understand the idea of factories, and please be patient with me when I ask these questions and make these comments - they are meant as what is *hopefully* constructive feedback.

So here goes.

I was looking at the 'Commands' in Spring RCP, and I noticed they seemed to follow the factory pattern of some (many?) of the other RCP classes in that they looked more like factories than what I am used to as a command. The first thing that caught my eye in this regard was the fact that they were coupled to various UI components via the 'createButton', 'createMenuItem', et. al., type methods.

This seems wrong to me for several reasons:

a) What happens when I (or someone else) needs/wants to add a new type of GUI control? Or maybe even a non-GUI control, like a voice control for the disabled to invoke some action in the UI via a verbal command? I have to either extend the command framework (often not desirable), or I would have to write my own. Either way, highly coupled and not very bean/Spring like.

b) Not good for reuse. In a previous gig, we had commands that were used in the Swing app. They could also be used elsewhere. They were not coupled to any kind of UI from the perspective of the commands - they knew nothing about UI components. They simple knew how to do something. I need to go back and look, but as I recall, we simply had UI controls that invoked a command when the user caused them to invoke the command. This was before I started using Spring, so the commands to be invoked were hard coded into the UI control, but somewhat like Spring RCP, we could attach them to menus, buttons, whatever.

In a gig before that, we had commands that knew how to undo, and command groups that kept a history of past commands so you could do multiple undos (or not - sometimes commands could not be undone so we provided feedback in the UI for that). That was too long ago for me to remember how coupled they were to the UI, but I am going to be generous and say they weren't.

I have also seen transactional type behavior, and behavior where listeners could veto the execution of a command. Other aspects of commands, like whether they are enabled, progress, security and so on, could be provided *without* coupling them to the concept of a UI, much less a UI component.

What I am getting at here is that I would prefer to see and use a different type of command framework, one more decoupled, more flexible and more abstract/generic than that provided by Spring RCP. I would like to see some kind of framework for connecting that command framework to UI components, but in a generic and bean like manner.

Thanks for listening.