Howdy all! Last week I sent out some questions regarding a framework I would like to open-source and asked where I should put it. Should I put it in Jakarta, Taglibs or even another open-source community? I received a few responses asking for more information so I wrote up something to outline the major goals/problems the framework attacks and a brief overview of how it attacks them. These are the major problems/goals that our framework attacks: Reusable and powerful components: Before custom tags there was very little ability to reuse code. Even with custom tags it isn't as simple as "put a textbox here and make sure that it has a value". The code to display, validate, and retrieve the value from an input is generic and should be extracted for re-use. Extracting view logic and loosely coupling the view: View logic should be kept on the view layer. The controller will get muddled if it needs to understand how to do form and field level validation, navigation, and adapt the model to something the view can understand. Having these responsibilities in the controller also causes the controller and the view to be too tightly integrated. Almost any change to the view will cause a corresponding change to the controller. For example, adding a pop-up confirmation box shouldn't require a change to the controller. View Controller relationship with better signals. How J2EE lacks: The J2EE version of the MVC pattern has only one signal between the view and its controller, post. This one signal is multiplexed and contains too much information that is irrelevant to the signal that is firing. Because of this scheme the controller and the view become so tightly integrated that a single change on the view will cause a change on the controller. This also causes complex logic in the controller to figure out what has really happened on the view. The view should have the ability to fire named signals when it has determined the signal to be well formed. These are the rough solutions we came up with: Signaling has a two-part solution, a good communications channel and extracting view logic. The communications channel can be anything so long as both sides, the view and the controller, understand how to manipulate it. The Velocity project has a context that performs this function. (see http://jakarta.apache.org/velocity/developer-guide.html#context <http://jakarta.apache.org/velocity/developer-guide.html#context> ) We chose to make our communications channel more hierarchical, sort of like a file system, but the implementation could be done in many ways. The problem with extracting view logic from the controller has always been that JSP pages are bad at holding complex logic. The solution is to make the logic as easy as possible to implement. We reduced the complexity on the page by creating an event model and reusable components that understand this model. With tools that understand this model and the communications channel, it is possible to create signals that fire with data from inputs and tie them to conditions from the model and state of the controls. This makes it possible to create a construct like: <signal name="save" condition="isClicked(submitButton) && pageIsValid()"> <copyValue from"FirstNameTextBox.value" to "firstName"> <copyValue from"LastNameTextBox.value" to "lastName"> </signal> This construct will fire the signal "save" only when the user has clicked the submitButton and there are no errors on the page. The data that goes with the signal comes from FirstNameTextBox.value and LastNameTextBox.value. Because the reusable components understand how to tell the page they have errors, validation rules can be encoded in them. So the reusable components would look something like this: <textbox name="FirstNameTextBox" allowempty="false" value="firstName"/> <textbox name="LastNameTextBox" allowempty="false" value="lastName"/> <button name="submitButton" /> Combining these three basic concepts, improved signaling, a communications channel, and fully encapsulated controls makes a view that is flexible and powerful. Add to that the fact that the view is loosely coupled to the controller, allowing for more parallel development, and you have a solid system for solving the View/Controller relationship problems. I hope this answers enough questions about the goals and layout of this framework to suggest how it should be open-sourced. I still haven't been given the ok to release source but I would be happy to go into more detail on the exact mechanisms that we created. Thanx for your time! -Jeff Ward
