My approach targets the performace, maintainability, sharability, and configurability by "dynamic technologies" such as reflection, mapping, and name convention. See the solution diagram Show details
As I mentioned, the "better" solution means that it should have
-
1). no hard-coded section at all (in other words, no change should be made for value building/loading in application tier
when thins are changed in the business tier.),
- Controllers
- Spring configuration files
- JSP views
- See the solution hereShow details
As we can see from the previous two extreme cases, hard-coded areas occur in three places:
To remove them, I first introduced my own binding class, ReflectDataBinder. This custom binder parses the incoming HttpRequest to extract parameters as parts of business beans. It instantiates those business beans and fills them up with the data carried by parameters using Spring's DataBinder. So when my framework users subclass the general form controller, ReflectFormController and override the customized onSubmit, for example in BambooAdminEditForm2Controller, what they see is the beanMap instead of Command as the gievn parameter
-
public ModelAndView onSubmit(Map beanMap) throws ServletException {
...
}
where beanMap contains all the ready-to-use business beans carried by the HttpRequest. As you can see in BambooAdminEditForm2Controller, users can use the business beans to invoke APIs of next tier right away. So the hard-coded value building area in the controllers is eliminated. On other words, I made the field level data transparent to my framework users and only expose bean level objects to users. A further improvement will be done to provide some default behavior such as save all the business beans in the super controller class so that for most "common" controllers, there is nothing to implement in their onSubmit. Before I move on, I need to explaint a little bit about how I can identify which parameter belong to what business beans. The major shortage for a command object or an "ActionForm" is that it appears as a single object. That is, Spring or Struts is able to bind http parameters to a single object by default since it only support signle command or ActionForm. In order to bind parameters on to multiple beans, I need to have a way to indicate the relation between a bean and its fields(parameters). There are two links I need to make: 1). a link between a bean symbol(or tile name) and a field; 2). a link between the tile name and the bean info like class name an so on. This bean symbol (tile name) represent not just a bean but also identify a piece of physical screen (I will talk about the "tile" concenpt later). The first link is achieved by using the tile name as a prefix of the field name in html. Each field name has a format of tileName.fieldName. This will tell my customized binder the field belong to what bean. Two classes are introduced to hold information about the tile. TileInfo contain tile level UI information while FieldInfo describes the field. A map, BEAN_MAP, is built initially when the appication or business is loaded. It contains all the bean information. To make demo codes simpler, I place the bean info in a static block but the bean info should really reside in xml configuration files and part of them should be automatically generated according to backend business beans. The keys in this map are the tile names so I link the bean info to the http parameters in this way. Next, I need to remove the hard-coded content in springapp-servlet.xml. The reason concrete information exists in the config file is that we used concrete command class for form controllers. So I fixed the problem by using a generaic command, BeanMapCommand, where map is used. And again, tile names are used as keys in the map. At last, I need to eliminate concrete information about particular beans from JSP views. Similar to the problem in configuration area, the problem is that we use concrete views for beans. Giving each bean a concrete view is really not a good idea (but most people keep doing it since it is simple to build but hard to maintain). Let's pick a concrete example, in the popup screen, content of two beans appear in the lower subframe, Bamboo and Source. They have the same type of view, form. That is, they should appear on the page as two instance of form view, just filled with different data. Under sharing view concept, I built a form view as a tag file, form.tag. All the business beans with a form view will share this tag. As you can see in the tag, there is no any information about a particular bean.
Show details
2). no wastful "ActionForms"
- See the solution hereShow details
I actually still have the "ActionForm", BeanMapCommand, but there is no binding when constructing. So I will assume that is almost "eliminated". Maybe I can find a better way to still used form controller as my ReflectFormController's super class without using any command.
3). completely isolate presentation from business.
- See the solution hereShow details
As you can see in the form.tag and bamboo_admin_edit2.jsp, there is no any information about objects Bamboo and Source. References (or symbols), tile names "Bamboo" and "Source", are used to link the view to backend business beans. So presentation layer is totally isolated from business layer.
And additionally, I also
4). have beans share a single view of a type.
- See the solution hereShow details
As I described above, I only used a single view(tag) for a particular type of view such as form or table. This achievement will dramatically boost maintainability and consistency. You will see it will also provide benefit to client-side validation, compatible with tools to enable plug-inability and so on. Concept "Tile" is used to represent a physical area in a page web. My "Tile" is different from those introduced by Struts. As you can see, my tile is a micro MVC which couple a business bean at the business tier with a view at the presentation tier. In a tile, the TileController works as a controller. A tag, for example form.tag, as the view and the business bean, say Bamboo appears as the model. A tile encapsolates all the communication activity between the business bean and users. It is ready to be plugged in by tools. And it could be highly configable since the beanInfo should reside outside of the application container in xml configuration files.
B. See the page with live code for Reflection style here
C. ConclusionShow details
I think my solution achieve following goals:
- Higher performance. The ActionForm construction is elimited and business beans are constructed directly from http parameters.
- Higher maintainability. 1). Hard-coded value building and loading is elimited; 2).View is shared so that no hard-coded in view (tags) either; 3). A general command object is used so no hard-coded in configuration area.
- Better isolation between presentation layer and business layer. Reflection is used to elimited business info from presentation area.
- Higher configability. Bean info resides in configuration files instead of hard-coded.
D. Source CodesShow details
- The source files involves in thhis approach
- bamboo_admin_edit2.jsp
- form.tag
- Bamboo.java
- Source.java
- Constant.java
- Field.java
- FieldInfo.java
- TileInfo.java
- TileController.java
- BambooManager.java
- BambooManagerDao.java
- BambooManagerDaoJdbc.java
- ReflectFormController.java
- BambooAdminEditForm2Controller.java
- ReflectDataBinder.java
- BeanMapCommand.java
- springapp-servlet.xml
- Other related source files
The view
The Business Data
The Basic Data Containers
The Business Tier APIs
The DAO
The Controller
The Binder
The Command
The Configuration
Show details