beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <>
Subject Re: [SimpleTags] Discussion
Date Wed, 19 Oct 2005 20:17:41 GMT
What I generally feel is that we should really have only one tag library.
The confusion of two tag libraries that are basically similar from an API
perspective may be hard to overcome. If someone were to learn the current
tag set and then need a new feature like (AJAX) they need to switch. I think
that we would want to deprecate the current tag set and then support it for
a while until the new features become compelling enough that 90% of pages
use the new tag set.

I don't think keeping a tag library alive is the cost, but adding feature to
two would be very expensive. I know your not advocating this, but it seems
if your not adding features to one tag set and you have a replacement tag
set that you are doing feature work in, the first one is deprecated whether
you call it that or not.

On 10/19/05, Rich Feit <> wrote:
> This seems great to me. My first question is, can we put your other two
> emails out on the wiki (maybe linked off a new page
> )? I think they're really
> helpful as background.
> Two comments below...
> Daryl Olander wrote:
> >This thread is intended to discuss the SimpleTags and if we go forward
> with
> >them or not.
> >
> >These are what I think are the advantages of creating a new tag set
> >
> >1) It separates the UI logic into a light weight component model
> (Behaviors)
> >in the same way JSF did, in fact rendering itself is also separate.
> >2) It cleanly issolates itself from the Servlet and PageFlow dependencies
> >3) It offers a significantly cleaner base implimentation from which we
> can
> >add AJAX and other tag features
> >4) It is based on the JSP Simple tags and provides a single base class
> >5) It can be adopted as a UI layer in Velocity and possible Spring
> WebFlow
> >or Clarity
> >
> >There are a bunch of disadvantages
> >1) It's a new tag library and we already have a good library (from the
> users
> >perspective)
> >2) We would have to move forward all of the tags (Databinding, Templates,
> >Tree, etc)
> >3) The upgrade is straight forward, but not "perfect". Some features like
> >JavaScript and Error reporting work differently, in a well formed
> document,
> >they work the same.
> >
> >There are a number of issues unresolved:
> >1) Should the Tag API match 100% (better for upgrade) or do we cleanup
> the
> >API (remove some of the struts like support from Form for example)?
> >2) Do we simply deprecate the old tag library or keep it alive for simple
> >enhancements and bug fixes while adding new features like AJAX to the new
> >tag library?
> >
> >
> >
> These are hard questions. Given that we went 1.0 with the old tag set,
> I personally feel that we should keep it alive (but not with new
> features), and not deprecate it. This takes off some of the pressure to
> have a 100% match between the APIs/attributes. Does that seem
> reasonable, or will it be a huge burden?
> Rich
> >Thoughts?
> >
> >
> >

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