beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: [SimpleTags] Discussion
Date Thu, 20 Oct 2005 16:51:33 GMT
I do see your point, and I think you're right about the confusion of two
non-deprecated tag libraries.  My main concern is about ripping away the
tag library we gave people in 1.0 without having an easy migration story
(which we wouldn't if we did the cleanup of attributes that you're
talking about).  Could we either:

    - officially deprecate the tag library, but support it for one
*extra* major release?
    - forgo some of the attribute cleanup to make the two tag sets more
compatible from the user's point of view?

Rich

Daryl Olander wrote:

>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 <richfeit@gmail.com> 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
>>http://wiki.apache.org/beehive/FeatureDesign )? 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?
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>  
>

Mime
View raw message