You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Daryl Olander <do...@gmail.com> on 2005/10/19 18:52:04 UTC
[SimpleTags] Discussion
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?
Thoughts?
Re: [SimpleTags] Discussion
Posted by Rich Feit <ri...@gmail.com>.
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 <ri...@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?
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: [SimpleTags] Discussion
Posted by Daryl Olander <do...@gmail.com>.
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 <ri...@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?
> >
> >
> >
>
>
Re: [SimpleTags] Discussion
Posted by Rich Feit <ri...@gmail.com>.
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?
>
>
>