Details about the framework

["Ward, Jeff" <jw...@BenefitPoint.com>]

  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