I'm about to check in some work that is currently "prototype" in nature. Basically, the architecture of the tags has really bothered me for a while, there are a number of design decisions made in the original tag library (pre-beehive) that really affected the design and implementation. My prototype work is an attempt to clean up the overall architecture. The problems with the current tag library are related to the following design decisions made very early on:
1) All features always work -- What this means is that things like JavaScript and error reporting work with or without certain tags. For example, when you have the <netui:body> tag, it is responsible for output of the framework generate script and errors. If you don't have this, then the <netui:html> tag will output these features. If you don't have either, we output things in-line. The result is that every Script and error API will either append to the response stream or pass back a String that must be appended to the response string by the JSP tag. 2) Pre JSP 2.0 -- The original tags (pre-beehive) were build on the classic tags. In the Beehive 1.0 release, some tags have moved to the new SimpleTag hierarchy. The result is there are two base classes in the tags (AbstractClassicTag and AbstractSimpleTag) which provide low level features that are duplicated between the two classes. We didn't switch the tag hierarchy to the simple tags because we wanted to continue to support pre-beehive pages that may have scriptlet in the JSP pages. 3) Base services provided by the base classes -- The original design has all of the services provided on the base classes (Error reporting, Naming, Scripting, etc.) The problem with this is that in combination with 1 above, there is some seriously strange logic that has to walk the page's tag hierarchy looking for "feature providers" and if their not found has a separate path for handling the feature locally. It also means that at times the tags have very strange relationships with the "feature providers" because they may not exist. (See how the ScriptRequestState help mediates the relationship between a tag the IScriptReporter.) A couple of weeks ago, I did a little prototyping to see how I could use the core features of the tags inside a velocity based UI. The big problem with this is that the UI is all in the JSP tags and separating this out into a layer that is called from velocity and JSP tags leads to further "really bad OO design". Lets call this UI layer, the tag "behavior". The reason for the bad OO affect is that I tried to do it and maintain backward compatibility in the tag API. This leads to "everything is public" in the behavior layer, and all the bad architecture from 1 and 3 creeps into the new layer. So I started a brand new tag library that address the 3 issues above plus two additional concerns: 1) The behaviors are UI agnostic. Basically, the behaviors need to be abstracted away from JSP (PageContext) and even further, Servlet. The goal for the behaviors is that they can run in JSP or Velocity with only a simple adaptor providing abstraction for Request and Response. 2) The behaviors are Framework agnostic. The primary reason for this,is that it would be nice if we could possibly run these on something like Clarity in the future. Again, we will provide a framework adaptor providing an abstraction for the core framework. The result is a new tag library (prototype) that I'm going to check in. I'm doing this so we can begin to evaluate if we want to take this step for real inside of beehive and to get feedback on the idea's and also the architecture. Early feedback can only make this better. In future mails, I'm going to detail the new architectural details and also what the impact may be on beehive in general if we go in this direction. Daryl
