beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject [SimpleTags] Introducing SimpleTags (long)
Date Wed, 19 Oct 2005 00:39:46 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message