What's So Magic About This?
It is common for architects to provide developers with programming interfaces and plug points if they intend to develop a framework that can truly be flexible. A framework like Hibernate provides the software developer with interfaces that the developer can choose to implement in order to enable lifecycle callbacks. Many web frameworks, like Struts, provide an Action interface that controllers must implement.
It can be tricky business to provide the software developer with the appropriate plug points that allows the developer the freedom and flexibility to create software that doesn't follow a rigid pattern, yet retains its usefulness and familiararity. In addition, Spring Rich utilizes Spring's IoC container as a means of defining these extension points, therefore the framework needs a way of pulling these alternate bean definitions from Spring's application context.
The framework accomplishes the discovery of the framework extension points by means of hardcoded bean ids that it attempts to locate in the application context. If the bean id does not appear in the context, Spring Rich usually provides a default implementation of the particular bean it requires. Because it is not obvious to the developer what the necessary bean ids are called, they are sometimes referred to as magic names. Hopefully, the following chart will help remove some of the magic.
| Magic Name |
Bean Type |
Default |
Purpose |
| application |
org. springframework. richclient. application. Application |
None (Required) |
This class is used by the ApplicationLauncher to initialize the application. It is responsible for opening the initial window of the application. |
| applicationWindowPrototype |
org. springframework. richclient. application. ApplicationWindow |
org. springframework. richclient. application. support. DefaultApplicationWindow |
The ApplicationWindow implementation defines the application's JFrame and the major components held within, such as the menu, toolbar, status bar, and commands. It also is responsible for creating and initializing the ApplicationPage implementation by using defaultApplicationPagePrototype (cf. below). This bean must be a prototype (i.e. non-singleton: singleton="false"). |
| windowCommandManager |
org. springframework. richclient. application. support. ApplicationWindowCommandManager |
ApplicationWindowCommandManager with no shared commands. |
appears to hold an application's shared commands. |
| menuBar |
org. springframework. richclient. command.CommandGroupFactoryBean |
CommandGroup without any menu commands |
A factory bean that returns instances of CommandGroup. Command group will contain the list of commands in the application's menu bar. |
| toolBar |
org. springframework. richclient. command.CommandGroupFactoryBean |
CommandGroup without any toolbar commands |
A factory bean that returns instances of CommandGroup. Command group will contain the list of commands in the application's toolbar |
| defaultApplicationPagePrototype |
org. springframework. richclient. application. support. DefaultApplicationPage |
DefaultApplicationPage with DefaultApplicationWindow as the application window. |
Whenever a new ApplicationWindow is created, an ApplicationPage describing the page layout is instantiated by retrieving this bean from the context. This bean must be a prototype (i.e. non-singleton: singleton="false"). |
There are many other magic names defined in the framework. This is intended only as a start for now.
