Additional UI tags

[Tom Schneider <sc...@gmail.com>]

Hello,
I've been working with webwork since June.  My company migrated from a 
home-grown webframework to webwork and it has been a very good 
experience.  I'm excited to see how struts2 can improve on an already 
top-notch framework.

In the process of integrating webwork with our software, I implemented 
several UI tags that probably could be used on other projects.  I wanted 
to get a feel for whether there was a desire to add these tags to the 
core struts project.  Although there are other open source tags that 
implement this functionality, we leverage the template based nature of 
the UI tags very heavily and wanted tags that allowed us this type of 
customization.

Pager - the pager tag is used to display a small pager display to allow 
pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is used on 
almost all the pages where we have lists of data.

SortColumn - the sort column tag displays the column name, the current 
sort direction and is hyperlinked so that the sort direction/selected 
sort column can be changed (e.g. Name ^ or Name v)

So, my question is: Is there any interest in adding these kinds of tags 
to the core struts tag library, or should these be separate?  I would 
think there would be enough other projects out there that would need 
these types of tags to warrant it, however, I've been doing only 
database apps for the last 2 years, so my perspective may be skewed a bit.
Thanks,
Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Ian Roughley <ia...@fdar.com>]

And not to mention that debugging for new users is not a trivial task!

/Ian



Don Brown wrote:
> The question is do we want to create one Struts tag library that does 
> everything, or focus on tags that require close ties with our 
> framework?  While I like the idea of providing more features and tags 
> to our users, I wonder if within Struts is the best place to host it...
>
> Don
>
> Ted Husted wrote:
>> I know I've implemented paging a dozen different ways, and reducing to
>> a tag of our own sounds like a good idea. Ditto with sorted tables. If
>> you wanted to contribute the tags, the thing to do would be to file a
>> CLA and open a JIRA ticket with the code attached,.
>>
>> * http://apache.org/licenses/#clas
>>
>> -Ted.
>>
>> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>>> Hello,
>>> I've been working with webwork since June.  My company migrated from a
>>> home-grown webframework to webwork and it has been a very good
>>> experience.  I'm excited to see how struts2 can improve on an already
>>> top-notch framework.
>>>
>>> In the process of integrating webwork with our software, I implemented
>>> several UI tags that probably could be used on other projects.  I 
>>> wanted
>>> to get a feel for whether there was a desire to add these tags to the
>>> core struts project.  Although there are other open source tags that
>>> implement this functionality, we leverage the template based nature of
>>> the UI tags very heavily and wanted tags that allowed us this type of
>>> customization.
>>>
>>> Pager - the pager tag is used to display a small pager display to allow
>>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is 
>>> used on
>>> almost all the pages where we have lists of data.
>>>
>>> SortColumn - the sort column tag displays the column name, the current
>>> sort direction and is hyperlinked so that the sort direction/selected
>>> sort column can be changed (e.g. Name ^ or Name v)
>>>
>>> So, my question is: Is there any interest in adding these kinds of tags
>>> to the core struts tag library, or should these be separate?  I would
>>> think there would be enough other projects out there that would need
>>> these types of tags to warrant it, however, I've been doing only
>>> database apps for the last 2 years, so my perspective may be skewed 
>>> a bit.
>>> Thanks,
>>> Tom
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Mark Menard <ma...@mjm.net>]

On 12/12/06 4:31 PM, "Ted Husted" <hu...@apache.org> wrote:

> A plugin for enhanced tags, like treeview, seems reasonable, leaving
> the core tags to concentrate on cases with direct HTML 4 corrollaries,
> but that's something we could sort out for the next GA series.

I like this, using plugins. On my list to do is to a version of the existing
UI tags that can take random properties. ex:

    <s:textfield myproperty="%{someBean.someProperty}" .... />

I was personally thinking that this would be best as a plugin.

Anyway, that's my highly discounted $0.02(US),

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Ted Husted <hu...@apache.org>]

A plugin for enhanced tags, like treeview, seems reasonable, leaving
the core tags to concentrate on cases with direct HTML 4 corrollaries,
but that's something we could sort out for the next GA series.

-Ted.

On 12/12/06, Tom Schneider <sc...@gmail.com> wrote:
> > Don Brown wrote:
> >> The question is do we want to create one Struts tag library that does
> >> everything, or focus on tags that require close ties with our
> >> framework?  While I like the idea of providing more features and tags
> >> to our users, I wonder if within Struts is the best place to host it...
> >>
> That really is the crux of my question, does this belong in struts
> proper, as a 'plug-in' module, or as a complete separate project?  My
> understanding from the ww forums is that the table tag is there, but no
> one was really supporting it.  (And briefly looking at it, I was not
> real impressed with it)  My issue with the DisplayTag is that is doesn't
> integrate as nicely with the ftl-backed UI tags--along with the fact
> that you can't break out the individual pieces.  (There are screens
> where I only need paging, but it's not a table, or it's a table with
> subheading that DisplayTag doesn't support)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Tom Schneider <sc...@gmail.com>]

>>>>
>> That really is the crux of my question, does this belong in struts 
>> proper, as a 'plug-in' module, or as a complete separate project?  My 
>> understanding from the ww forums is that the table tag is there, but 
>> no one was really supporting it.  (And briefly looking at it, I was 
>> not real impressed with it)  
>
> I was planning to check it out, and see if some integration with Dojo 
> was possible, and add an example to showcase, after 2.0.2.
>
>> My issue with the DisplayTag is that is doesn't integrate as nicely 
>> with the ftl-backed UI tags--along with the fact that you can't break 
>> out the individual pieces.  (There are screens where I only need 
>> paging, but it's not a table, or it's a table with subheading that 
>> DisplayTag doesn't support)
>
> You are right, I was thinking about table pagination, but there are 
> other scenarios where it would be helpful. Follow Ted's advise and add 
> it to a jira ticket, it won't hurt anyway :)
>
> musachy
>
I plan on doing that as soon as I get the CLA back from our legal 
person.  I checked with the CTO and he didn't have an issue with it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Musachy Barroso <mb...@wfscorp.com>]

Tom Schneider wrote:
> Musachy Barroso wrote:
>> We also have a table tag, which I have never seen and I don't know if 
>> it works. On that same thought, DisplayTag has a lot of stuff which 
>> would be pointless to duplicate. But I could say the same thing about 
>> the ajax tags anyway...
>>
>> musachy
>>
>> Don Brown wrote:
>>> The question is do we want to create one Struts tag library that 
>>> does everything, or focus on tags that require close ties with our 
>>> framework?  While I like the idea of providing more features and 
>>> tags to our users, I wonder if within Struts is the best place to 
>>> host it...
>>>
> That really is the crux of my question, does this belong in struts 
> proper, as a 'plug-in' module, or as a complete separate project?  My 
> understanding from the ww forums is that the table tag is there, but 
> no one was really supporting it.  (And briefly looking at it, I was 
> not real impressed with it)  

I was planning to check it out, and see if some integration with Dojo 
was possible, and add an example to showcase, after 2.0.2.

> My issue with the DisplayTag is that is doesn't integrate as nicely 
> with the ftl-backed UI tags--along with the fact that you can't break 
> out the individual pieces.  (There are screens where I only need 
> paging, but it's not a table, or it's a table with subheading that 
> DisplayTag doesn't support)

You are right, I was thinking about table pagination, but there are 
other scenarios where it would be helpful. Follow Ted's advise and add 
it to a jira ticket, it won't hurt anyway :)

musachy

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Tom Schneider <sc...@gmail.com>]

Musachy Barroso wrote:
> We also have a table tag, which I have never seen and I don't know if 
> it works. On that same thought, DisplayTag has a lot of stuff which 
> would be pointless to duplicate. But I could say the same thing about 
> the ajax tags anyway...
>
> musachy
>
> Don Brown wrote:
>> The question is do we want to create one Struts tag library that does 
>> everything, or focus on tags that require close ties with our 
>> framework?  While I like the idea of providing more features and tags 
>> to our users, I wonder if within Struts is the best place to host it...
>>
That really is the crux of my question, does this belong in struts 
proper, as a 'plug-in' module, or as a complete separate project?  My 
understanding from the ww forums is that the table tag is there, but no 
one was really supporting it.  (And briefly looking at it, I was not 
real impressed with it)  My issue with the DisplayTag is that is doesn't 
integrate as nicely with the ftl-backed UI tags--along with the fact 
that you can't break out the individual pieces.  (There are screens 
where I only need paging, but it's not a table, or it's a table with 
subheading that DisplayTag doesn't support)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Musachy Barroso <mb...@wfscorp.com>]

We also have a table tag, which I have never seen and I don't know if it 
works. On that same thought, DisplayTag has a lot of stuff which would 
be pointless to duplicate. But I could say the same thing about the ajax 
tags anyway...

musachy

Don Brown wrote:
> The question is do we want to create one Struts tag library that does 
> everything, or focus on tags that require close ties with our 
> framework?  While I like the idea of providing more features and tags 
> to our users, I wonder if within Struts is the best place to host it...
>
> Don
>
> Ted Husted wrote:
>> I know I've implemented paging a dozen different ways, and reducing to
>> a tag of our own sounds like a good idea. Ditto with sorted tables. If
>> you wanted to contribute the tags, the thing to do would be to file a
>> CLA and open a JIRA ticket with the code attached,.
>>
>> * http://apache.org/licenses/#clas
>>
>> -Ted.
>>
>> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>>> Hello,
>>> I've been working with webwork since June.  My company migrated from a
>>> home-grown webframework to webwork and it has been a very good
>>> experience.  I'm excited to see how struts2 can improve on an already
>>> top-notch framework.
>>>
>>> In the process of integrating webwork with our software, I implemented
>>> several UI tags that probably could be used on other projects.  I 
>>> wanted
>>> to get a feel for whether there was a desire to add these tags to the
>>> core struts project.  Although there are other open source tags that
>>> implement this functionality, we leverage the template based nature of
>>> the UI tags very heavily and wanted tags that allowed us this type of
>>> customization.
>>>
>>> Pager - the pager tag is used to display a small pager display to allow
>>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is 
>>> used on
>>> almost all the pages where we have lists of data.
>>>
>>> SortColumn - the sort column tag displays the column name, the current
>>> sort direction and is hyperlinked so that the sort direction/selected
>>> sort column can be changed (e.g. Name ^ or Name v)
>>>
>>> So, my question is: Is there any interest in adding these kinds of tags
>>> to the core struts tag library, or should these be separate?  I would
>>> think there would be enough other projects out there that would need
>>> these types of tags to warrant it, however, I've been doing only
>>> database apps for the last 2 years, so my perspective may be skewed 
>>> a bit.
>>> Thanks,
>>> Tom
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Musachy Barroso <mb...@wfscorp.com>]

Sounds good, and easier to hack with later,  to me :)

musachy
Ted Husted wrote:
> Meanwhile, what about Don's suggestion that we keep the wrappers but
> drop the theme and put the tags into their own library or plugin? We'd
> need to do something like that first, regardless of where the code
> ultimately lives.
>
> -Ted.
>
> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>> Probably a better integration in some places...but it would definitely
>> be worth considering not to duplicate what others are doing.
>>
>> musachy
>>
>> Don Brown wrote:
>> > Well, if there is an external project that already does everything we
>> > want, then why don't we just use them?  I'm all for minimizing
>> > duplication.  What value does having our own ajax tag library provide?
>> >
>> > Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Ian Roughley <ia...@fdar.com>]

Personally, I have only WW2 apps with the ajax theme in production and 
there is no intention of upgrading anytime soon.  I would also be 
surprised if any of the other committers have projects based on the ajax 
theme in production.

/Ian


Ted Husted wrote:
> On 12/18/06, Ian Roughley <ia...@fdar.com> wrote:
>> > On the other hand, ripping the ajax tags out would affect backwards
>> > compatibility.  Are a lot of users out there using these tags?  Could
>> > the migration be simple or would it involve too much effort?
>> I have never gotten much of an answer whenever I queries the users for
>> who was using the ajax tags.  Usually, about 3-4 weeks after a new
>> change was made I would get some feedback.  Personally, it would seem
>> that most people are either (a) not using them, or (b) rolling their 
>> own.
>>
>> I'm not sure how much backward compatibility would be affected - as if
>> the same attributes that are used now could be used in the ajax plug-in
>> tags.  So if you are upgrading you'd just need to ensure that the
>> plug-in is there.  I haven't checked lately, but I think there is quiet
>> a difference from WW2 to Struts2 for the ajax tags (i.e. new attributes,
>> new dojo version, new tags).
>
> If we extract the ajax support into a struts-dojo plugin, it would
> pave the way for alternative plugins. If the change in ajax support is
> an issue for someone, then they could roll another plugin based on the
> struts-dojo plugin. Likewise for other ajax libaries.
>
> The key question is whether the Struts committers are using the Ajax
> theme and how the change is going to affect the applications we have
> in production. We can't drag around code that people are not going to
> support, and we can't support code that we don't use ourselves.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Ted Husted <hu...@apache.org>]

On 12/18/06, Ian Roughley <ia...@fdar.com> wrote:
> > On the other hand, ripping the ajax tags out would affect backwards
> > compatibility.  Are a lot of users out there using these tags?  Could
> > the migration be simple or would it involve too much effort?
> I have never gotten much of an answer whenever I queries the users for
> who was using the ajax tags.  Usually, about 3-4 weeks after a new
> change was made I would get some feedback.  Personally, it would seem
> that most people are either (a) not using them, or (b) rolling their own.
>
> I'm not sure how much backward compatibility would be affected - as if
> the same attributes that are used now could be used in the ajax plug-in
> tags.  So if you are upgrading you'd just need to ensure that the
> plug-in is there.  I haven't checked lately, but I think there is quiet
> a difference from WW2 to Struts2 for the ajax tags (i.e. new attributes,
> new dojo version, new tags).

If we extract the ajax support into a struts-dojo plugin, it would
pave the way for alternative plugins. If the change in ajax support is
an issue for someone, then they could roll another plugin based on the
struts-dojo plugin. Likewise for other ajax libaries.

The key question is whether the Struts committers are using the Ajax
theme and how the change is going to affect the applications we have
in production. We can't drag around code that people are not going to
support, and we can't support code that we don't use ourselves.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Musachy Barroso <mb...@wfscorp.com>]

Just to complicate it further we have the special case of the 
Autocompleter which has communication if it is used in the ajax theme, 
and just javascript if in the simple theme (it should be xhtml). The 
idea of having a custom dojo profile is good.I logged a jira ticket for 
it a couple of weeks ago (WW-1536).

musachy

Martin Cooper wrote:
> On 12/19/06, Don Brown <mr...@twdata.org> wrote:
>>
>> The tooltips could use another library, and either the calendar could
>> use a slimmed down version of dojo for that widget or another library.
>> The problem is currently our xhtml theme included dojo, which I kinda
>> regret.  It does seem like there should be a more clear separation.
>
>
> We could very easily define our own minimal Dojo profile, so that we 
> pull in
> only what we need for these. I'd certainly prefer that to using different
> libraries, first because having two implementations complicates 
> things, and
> second because it would be strange to users to have different 
> renderings /
> behaviours for "the same" functionality.
>
> The question in my mind is how we want to delineate the pieces in the 
> first
> place. Half the people who talk about AJAX couldn't differentiate between
> what is and what is not AJAX in the first place, equating AJAX with 
> DHTML.
> We could decide to split off the part that is communication-related, but
> that too can lead to an unnatural divide, with some DHTML widgets
> incorporating communication and others not. And then if we added
> communication support to a widget that previously didn't have it, it 
> would
> have to move, which seems less than optimal.
>
> So what are we really trying to split off here? AJAX support? DHTML 
> support?
> Once we can clearly define what we want to do, we should be able to 
> find a
> way to make a clean split.
>
> -- 
> Martin Cooper
>
>
> Don
>>
>> Ian Roughley wrote:
>> > Just thought of a possible downside.
>> > Features that users may have expected as simple javascript / non-ajax,
>> > for example tool tip and calendar, are (I believe) now implemented
>> > using the dojo library.  So there is not a clean separation between
>> > those tags that have communication and those that don't.
>> > /Ian
>> >
>> >
>> >
>> > Don Brown wrote:
>> >> As much as I absolutely hate to say it, I think we need to resolve
>> >> this ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2
>> >> gets so much attention by the community that to have a brittle,
>> >> poorly supported feature that we hope to remove in the next release
>> >> will only bring confusion and rejection of Struts 2 as a whole.
>> >>
>> >> If we created a new tag library, our current tags should be able to
>> >> be very much simplified as a lot of the attributes would go away.
>> >> The new tags would be much clearer and easier to pick up without
>> >> having to explain themes and why certain attributes only work in
>> >> certain situations.
>> >>
>> >> On the other hand, ripping the ajax tags out would affect backwards
>> >> compatibility.  Are a lot of users out there using these tags?  Could
>> >> the migration be simple or would it involve too much effort?
>> >>
>> >> Don
>> >>
>> >> Ian Roughley wrote:
>> >>> The wrappers around the beans are there to provide accessors to new
>> >>> attributes needed by the ajax tags.  If we were to extract the tags
>> >>> into a separate taglib or library, I don't think we would need the
>> >>> wrappers.  The additionally required attributes would be contained
>> >>> on the new classes in the new library.  This would also remove the
>> >>> dependency of s2 on each ajax library we use (i.e. for dojo we need
>> >>> an additional attribute x & y, for prototype maybe we use y and add
>> >>> new attributes a & b).
>> >>>
>> >>> But I like the idea :)  It would also help with the more frequent
>> >>> dojo updates.
>> >>>
>> >>> /Ian
>> >>>
>> >>>
>> >>>
>> >>> Ted Husted wrote:
>> >>>> Meanwhile, what about Don's suggestion that we keep the wrappers 
>> but
>> >>>> drop the theme and put the tags into their own library or plugin?
>> We'd
>> >>>> need to do something like that first, regardless of where the code
>> >>>> ultimately lives.
>> >>>>
>> >>>> -Ted.
>> >>>>
>> >>>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>> >>>>> Probably a better integration in some places...but it would
>> >>>>> definitely
>> >>>>> be worth considering not to duplicate what others are doing.
>> >>>>>
>> >>>>> musachy
>> >>>>>
>> >>>>> Don Brown wrote:
>> >>>>> > Well, if there is an external project that already does
>> >>>>> everything we
>> >>>>> > want, then why don't we just use them?  I'm all for minimizing
>> >>>>> > duplication.  What value does having our own ajax tag library
>> >>>>> provide?
>> >>>>> >
>> >>>>> > Don
>> >>>>
>> >>>> 
>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >>>> For additional commands, e-mail: dev-help@struts.apache.org
>> >>>>
>> >>>
>> >>> 
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >>> For additional commands, e-mail: dev-help@struts.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Don Brown <mr...@twdata.org>]

That's a very good point.  What about making the cutoff any Dojo 
widget-related tags?  This would include the calendar tag.  I think it 
would be ok to split this off, since it is in no way compatible with the 
old calendar tag anyways.

We could use a very slimmed down version of Dojo for tooltips and IO in 
our core tags.  Would a user still be able to use the Dojo tags and our 
core tags if they both used Dojo?  Would we still have to bundle all of 
Dojo in our Struts 2 jar?

The reason I think we should spin off any tags that use Dojo widgets is 
that any attributes and behaviors are going to be very unique to the 
Dojo implementation.  The idea of the core tags is to define an abstract 
component and allow it to be rendered in different ways in different 
themes.  A close corollary to this notion is that the core behavior and 
attributes will be consistent by all themes.  If a theme swapped in 
another calendar implementation, for example, it would be drastically 
different both in attributes and behavior.

Don

Martin Cooper wrote:
> On 12/19/06, Don Brown <mr...@twdata.org> wrote:
>>
>> The tooltips could use another library, and either the calendar could
>> use a slimmed down version of dojo for that widget or another library.
>> The problem is currently our xhtml theme included dojo, which I kinda
>> regret.  It does seem like there should be a more clear separation.
>
>
> We could very easily define our own minimal Dojo profile, so that we 
> pull in
> only what we need for these. I'd certainly prefer that to using different
> libraries, first because having two implementations complicates 
> things, and
> second because it would be strange to users to have different 
> renderings /
> behaviours for "the same" functionality.
>
> The question in my mind is how we want to delineate the pieces in the 
> first
> place. Half the people who talk about AJAX couldn't differentiate between
> what is and what is not AJAX in the first place, equating AJAX with 
> DHTML.
> We could decide to split off the part that is communication-related, but
> that too can lead to an unnatural divide, with some DHTML widgets
> incorporating communication and others not. And then if we added
> communication support to a widget that previously didn't have it, it 
> would
> have to move, which seems less than optimal.
>
> So what are we really trying to split off here? AJAX support? DHTML 
> support?
> Once we can clearly define what we want to do, we should be able to 
> find a
> way to make a clean split.
>
> -- 
> Martin Cooper
>
>
> Don
>>
>> Ian Roughley wrote:
>> > Just thought of a possible downside.
>> > Features that users may have expected as simple javascript / non-ajax,
>> > for example tool tip and calendar, are (I believe) now implemented
>> > using the dojo library.  So there is not a clean separation between
>> > those tags that have communication and those that don't.
>> > /Ian
>> >
>> >
>> >
>> > Don Brown wrote:
>> >> As much as I absolutely hate to say it, I think we need to resolve
>> >> this ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2
>> >> gets so much attention by the community that to have a brittle,
>> >> poorly supported feature that we hope to remove in the next release
>> >> will only bring confusion and rejection of Struts 2 as a whole.
>> >>
>> >> If we created a new tag library, our current tags should be able to
>> >> be very much simplified as a lot of the attributes would go away.
>> >> The new tags would be much clearer and easier to pick up without
>> >> having to explain themes and why certain attributes only work in
>> >> certain situations.
>> >>
>> >> On the other hand, ripping the ajax tags out would affect backwards
>> >> compatibility.  Are a lot of users out there using these tags?  Could
>> >> the migration be simple or would it involve too much effort?
>> >>
>> >> Don
>> >>
>> >> Ian Roughley wrote:
>> >>> The wrappers around the beans are there to provide accessors to new
>> >>> attributes needed by the ajax tags.  If we were to extract the tags
>> >>> into a separate taglib or library, I don't think we would need the
>> >>> wrappers.  The additionally required attributes would be contained
>> >>> on the new classes in the new library.  This would also remove the
>> >>> dependency of s2 on each ajax library we use (i.e. for dojo we need
>> >>> an additional attribute x & y, for prototype maybe we use y and add
>> >>> new attributes a & b).
>> >>>
>> >>> But I like the idea :)  It would also help with the more frequent
>> >>> dojo updates.
>> >>>
>> >>> /Ian
>> >>>
>> >>>
>> >>>
>> >>> Ted Husted wrote:
>> >>>> Meanwhile, what about Don's suggestion that we keep the wrappers 
>> but
>> >>>> drop the theme and put the tags into their own library or plugin?
>> We'd
>> >>>> need to do something like that first, regardless of where the code
>> >>>> ultimately lives.
>> >>>>
>> >>>> -Ted.
>> >>>>
>> >>>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>> >>>>> Probably a better integration in some places...but it would
>> >>>>> definitely
>> >>>>> be worth considering not to duplicate what others are doing.
>> >>>>>
>> >>>>> musachy
>> >>>>>
>> >>>>> Don Brown wrote:
>> >>>>> > Well, if there is an external project that already does
>> >>>>> everything we
>> >>>>> > want, then why don't we just use them?  I'm all for minimizing
>> >>>>> > duplication.  What value does having our own ajax tag library
>> >>>>> provide?
>> >>>>> >
>> >>>>> > Don
>> >>>>
>> >>>> 
>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >>>> For additional commands, e-mail: dev-help@struts.apache.org
>> >>>>
>> >>>
>> >>> 
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >>> For additional commands, e-mail: dev-help@struts.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Martin Cooper <ma...@apache.org>]

On 12/19/06, Don Brown <mr...@twdata.org> wrote:
>
> The tooltips could use another library, and either the calendar could
> use a slimmed down version of dojo for that widget or another library.
> The problem is currently our xhtml theme included dojo, which I kinda
> regret.  It does seem like there should be a more clear separation.


We could very easily define our own minimal Dojo profile, so that we pull in
only what we need for these. I'd certainly prefer that to using different
libraries, first because having two implementations complicates things, and
second because it would be strange to users to have different renderings /
behaviours for "the same" functionality.

The question in my mind is how we want to delineate the pieces in the first
place. Half the people who talk about AJAX couldn't differentiate between
what is and what is not AJAX in the first place, equating AJAX with DHTML.
We could decide to split off the part that is communication-related, but
that too can lead to an unnatural divide, with some DHTML widgets
incorporating communication and others not. And then if we added
communication support to a widget that previously didn't have it, it would
have to move, which seems less than optimal.

So what are we really trying to split off here? AJAX support? DHTML support?
Once we can clearly define what we want to do, we should be able to find a
way to make a clean split.

--
Martin Cooper


Don
>
> Ian Roughley wrote:
> > Just thought of a possible downside.
> > Features that users may have expected as simple javascript / non-ajax,
> > for example tool tip and calendar, are (I believe) now implemented
> > using the dojo library.  So there is not a clean separation between
> > those tags that have communication and those that don't.
> > /Ian
> >
> >
> >
> > Don Brown wrote:
> >> As much as I absolutely hate to say it, I think we need to resolve
> >> this ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2
> >> gets so much attention by the community that to have a brittle,
> >> poorly supported feature that we hope to remove in the next release
> >> will only bring confusion and rejection of Struts 2 as a whole.
> >>
> >> If we created a new tag library, our current tags should be able to
> >> be very much simplified as a lot of the attributes would go away.
> >> The new tags would be much clearer and easier to pick up without
> >> having to explain themes and why certain attributes only work in
> >> certain situations.
> >>
> >> On the other hand, ripping the ajax tags out would affect backwards
> >> compatibility.  Are a lot of users out there using these tags?  Could
> >> the migration be simple or would it involve too much effort?
> >>
> >> Don
> >>
> >> Ian Roughley wrote:
> >>> The wrappers around the beans are there to provide accessors to new
> >>> attributes needed by the ajax tags.  If we were to extract the tags
> >>> into a separate taglib or library, I don't think we would need the
> >>> wrappers.  The additionally required attributes would be contained
> >>> on the new classes in the new library.  This would also remove the
> >>> dependency of s2 on each ajax library we use (i.e. for dojo we need
> >>> an additional attribute x & y, for prototype maybe we use y and add
> >>> new attributes a & b).
> >>>
> >>> But I like the idea :)  It would also help with the more frequent
> >>> dojo updates.
> >>>
> >>> /Ian
> >>>
> >>>
> >>>
> >>> Ted Husted wrote:
> >>>> Meanwhile, what about Don's suggestion that we keep the wrappers but
> >>>> drop the theme and put the tags into their own library or plugin?
> We'd
> >>>> need to do something like that first, regardless of where the code
> >>>> ultimately lives.
> >>>>
> >>>> -Ted.
> >>>>
> >>>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
> >>>>> Probably a better integration in some places...but it would
> >>>>> definitely
> >>>>> be worth considering not to duplicate what others are doing.
> >>>>>
> >>>>> musachy
> >>>>>
> >>>>> Don Brown wrote:
> >>>>> > Well, if there is an external project that already does
> >>>>> everything we
> >>>>> > want, then why don't we just use them?  I'm all for minimizing
> >>>>> > duplication.  What value does having our own ajax tag library
> >>>>> provide?
> >>>>> >
> >>>>> > Don
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Musachy Barroso <mb...@wfscorp.com>]

I agree with you 100%, I don't think there are many people using them, 
and for those who are, it wouldn't be a difficult task to adapt to them. 
On the other side, people are waiting for a release and ajax IMO is  not 
a major feature of struts, could we separate them into their own plugin, 
clean them up and make them "experimental" or something similar for this 
release?

musachy

Don Brown wrote:
> As much as I absolutely hate to say it, I think we need to resolve 
> this ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2 
> gets so much attention by the community that to have a brittle, poorly 
> supported feature that we hope to remove in the next release will only 
> bring confusion and rejection of Struts 2 as a whole.
>
> If we created a new tag library, our current tags should be able to be 
> very much simplified as a lot of the attributes would go away.  The 
> new tags would be much clearer and easier to pick up without having to 
> explain themes and why certain attributes only work in certain 
> situations.
>
> On the other hand, ripping the ajax tags out would affect backwards 
> compatibility.  Are a lot of users out there using these tags?  Could 
> the migration be simple or would it involve too much effort?
>
> Don
>
> Ian Roughley wrote:
>> The wrappers around the beans are there to provide accessors to new 
>> attributes needed by the ajax tags.  If we were to extract the tags 
>> into a separate taglib or library, I don't think we would need the 
>> wrappers.  The additionally required attributes would be contained on 
>> the new classes in the new library.  This would also remove the 
>> dependency of s2 on each ajax library we use (i.e. for dojo we need 
>> an additional attribute x & y, for prototype maybe we use y and add 
>> new attributes a & b).
>>
>> But I like the idea :)  It would also help with the more frequent 
>> dojo updates.
>>
>> /Ian
>>
>>
>>
>> Ted Husted wrote:
>>> Meanwhile, what about Don's suggestion that we keep the wrappers but
>>> drop the theme and put the tags into their own library or plugin? We'd
>>> need to do something like that first, regardless of where the code
>>> ultimately lives.
>>>
>>> -Ted.
>>>
>>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>>>> Probably a better integration in some places...but it would definitely
>>>> be worth considering not to duplicate what others are doing.
>>>>
>>>> musachy
>>>>
>>>> Don Brown wrote:
>>>> > Well, if there is an external project that already does 
>>>> everything we
>>>> > want, then why don't we just use them?  I'm all for minimizing
>>>> > duplication.  What value does having our own ajax tag library 
>>>> provide?
>>>> >
>>>> > Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Don Brown <mr...@twdata.org>]

The tooltips could use another library, and either the calendar could 
use a slimmed down version of dojo for that widget or another library.  
The problem is currently our xhtml theme included dojo, which I kinda 
regret.  It does seem like there should be a more clear separation.

Don

Ian Roughley wrote:
> Just thought of a possible downside.
> Features that users may have expected as simple javascript / non-ajax, 
> for example tool tip and calendar, are (I believe) now implemented 
> using the dojo library.  So there is not a clean separation between 
> those tags that have communication and those that don't.
> /Ian
>
>
>
> Don Brown wrote:
>> As much as I absolutely hate to say it, I think we need to resolve 
>> this ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2 
>> gets so much attention by the community that to have a brittle, 
>> poorly supported feature that we hope to remove in the next release 
>> will only bring confusion and rejection of Struts 2 as a whole.
>>
>> If we created a new tag library, our current tags should be able to 
>> be very much simplified as a lot of the attributes would go away.  
>> The new tags would be much clearer and easier to pick up without 
>> having to explain themes and why certain attributes only work in 
>> certain situations.
>>
>> On the other hand, ripping the ajax tags out would affect backwards 
>> compatibility.  Are a lot of users out there using these tags?  Could 
>> the migration be simple or would it involve too much effort?
>>
>> Don
>>
>> Ian Roughley wrote:
>>> The wrappers around the beans are there to provide accessors to new 
>>> attributes needed by the ajax tags.  If we were to extract the tags 
>>> into a separate taglib or library, I don't think we would need the 
>>> wrappers.  The additionally required attributes would be contained 
>>> on the new classes in the new library.  This would also remove the 
>>> dependency of s2 on each ajax library we use (i.e. for dojo we need 
>>> an additional attribute x & y, for prototype maybe we use y and add 
>>> new attributes a & b).
>>>
>>> But I like the idea :)  It would also help with the more frequent 
>>> dojo updates.
>>>
>>> /Ian
>>>
>>>
>>>
>>> Ted Husted wrote:
>>>> Meanwhile, what about Don's suggestion that we keep the wrappers but
>>>> drop the theme and put the tags into their own library or plugin? We'd
>>>> need to do something like that first, regardless of where the code
>>>> ultimately lives.
>>>>
>>>> -Ted.
>>>>
>>>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>>>>> Probably a better integration in some places...but it would 
>>>>> definitely
>>>>> be worth considering not to duplicate what others are doing.
>>>>>
>>>>> musachy
>>>>>
>>>>> Don Brown wrote:
>>>>> > Well, if there is an external project that already does 
>>>>> everything we
>>>>> > want, then why don't we just use them?  I'm all for minimizing
>>>>> > duplication.  What value does having our own ajax tag library 
>>>>> provide?
>>>>> >
>>>>> > Don
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Musachy Barroso <mb...@wfscorp.com>]

Yes, they are implemented using Dojo.

musachy

Ian Roughley wrote:
> Just thought of a possible downside.
> Features that users may have expected as simple javascript / non-ajax, 
> for example tool tip and calendar, are (I believe) now implemented 
> using the dojo library.  So there is not a clean separation between 
> those tags that have communication and those that don't.
> /Ian
>
>
>
> Don Brown wrote:
>> As much as I absolutely hate to say it, I think we need to resolve 
>> this ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2 
>> gets so much attention by the community that to have a brittle, 
>> poorly supported feature that we hope to remove in the next release 
>> will only bring confusion and rejection of Struts 2 as a whole.
>>
>> If we created a new tag library, our current tags should be able to 
>> be very much simplified as a lot of the attributes would go away.  
>> The new tags would be much clearer and easier to pick up without 
>> having to explain themes and why certain attributes only work in 
>> certain situations.
>>
>> On the other hand, ripping the ajax tags out would affect backwards 
>> compatibility.  Are a lot of users out there using these tags?  Could 
>> the migration be simple or would it involve too much effort?
>>
>> Don
>>
>> Ian Roughley wrote:
>>> The wrappers around the beans are there to provide accessors to new 
>>> attributes needed by the ajax tags.  If we were to extract the tags 
>>> into a separate taglib or library, I don't think we would need the 
>>> wrappers.  The additionally required attributes would be contained 
>>> on the new classes in the new library.  This would also remove the 
>>> dependency of s2 on each ajax library we use (i.e. for dojo we need 
>>> an additional attribute x & y, for prototype maybe we use y and add 
>>> new attributes a & b).
>>>
>>> But I like the idea :)  It would also help with the more frequent 
>>> dojo updates.
>>>
>>> /Ian
>>>
>>>
>>>
>>> Ted Husted wrote:
>>>> Meanwhile, what about Don's suggestion that we keep the wrappers but
>>>> drop the theme and put the tags into their own library or plugin? We'd
>>>> need to do something like that first, regardless of where the code
>>>> ultimately lives.
>>>>
>>>> -Ted.
>>>>
>>>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>>>>> Probably a better integration in some places...but it would 
>>>>> definitely
>>>>> be worth considering not to duplicate what others are doing.
>>>>>
>>>>> musachy
>>>>>
>>>>> Don Brown wrote:
>>>>> > Well, if there is an external project that already does 
>>>>> everything we
>>>>> > want, then why don't we just use them?  I'm all for minimizing
>>>>> > duplication.  What value does having our own ajax tag library 
>>>>> provide?
>>>>> >
>>>>> > Don
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Ian Roughley <ia...@fdar.com>]

Just thought of a possible downside. 

Features that users may have expected as simple javascript / non-ajax, 
for example tool tip and calendar, are (I believe) now implemented using 
the dojo library.  So there is not a clean separation between those tags 
that have communication and those that don't. 

/Ian



Don Brown wrote:
> As much as I absolutely hate to say it, I think we need to resolve 
> this ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2 
> gets so much attention by the community that to have a brittle, poorly 
> supported feature that we hope to remove in the next release will only 
> bring confusion and rejection of Struts 2 as a whole.
>
> If we created a new tag library, our current tags should be able to be 
> very much simplified as a lot of the attributes would go away.  The 
> new tags would be much clearer and easier to pick up without having to 
> explain themes and why certain attributes only work in certain 
> situations.
>
> On the other hand, ripping the ajax tags out would affect backwards 
> compatibility.  Are a lot of users out there using these tags?  Could 
> the migration be simple or would it involve too much effort?
>
> Don
>
> Ian Roughley wrote:
>> The wrappers around the beans are there to provide accessors to new 
>> attributes needed by the ajax tags.  If we were to extract the tags 
>> into a separate taglib or library, I don't think we would need the 
>> wrappers.  The additionally required attributes would be contained on 
>> the new classes in the new library.  This would also remove the 
>> dependency of s2 on each ajax library we use (i.e. for dojo we need 
>> an additional attribute x & y, for prototype maybe we use y and add 
>> new attributes a & b).
>>
>> But I like the idea :)  It would also help with the more frequent 
>> dojo updates.
>>
>> /Ian
>>
>>
>>
>> Ted Husted wrote:
>>> Meanwhile, what about Don's suggestion that we keep the wrappers but
>>> drop the theme and put the tags into their own library or plugin? We'd
>>> need to do something like that first, regardless of where the code
>>> ultimately lives.
>>>
>>> -Ted.
>>>
>>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>>>> Probably a better integration in some places...but it would definitely
>>>> be worth considering not to duplicate what others are doing.
>>>>
>>>> musachy
>>>>
>>>> Don Brown wrote:
>>>> > Well, if there is an external project that already does 
>>>> everything we
>>>> > want, then why don't we just use them?  I'm all for minimizing
>>>> > duplication.  What value does having our own ajax tag library 
>>>> provide?
>>>> >
>>>> > Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Ian Roughley <ia...@fdar.com>]

Don Brown wrote:
> As much as I absolutely hate to say it, I think we need to resolve 
> this ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2 
> gets so much attention by the community that to have a brittle, poorly 
> supported feature that we hope to remove in the next release will only 
> bring confusion and rejection of Struts 2 as a whole.
agreed.
>
> If we created a new tag library, our current tags should be able to be 
> very much simplified as a lot of the attributes would go away.  The 
> new tags would be much clearer and easier to pick up without having to 
> explain themes and why certain attributes only work in certain 
> situations.
Yes - much easier to explain tags.
>
> On the other hand, ripping the ajax tags out would affect backwards 
> compatibility.  Are a lot of users out there using these tags?  Could 
> the migration be simple or would it involve too much effort?
I have never gotten much of an answer whenever I queries the users for 
who was using the ajax tags.  Usually, about 3-4 weeks after a new 
change was made I would get some feedback.  Personally, it would seem 
that most people are either (a) not using them, or (b) rolling their own.

I'm not sure how much backward compatibility would be affected - as if 
the same attributes that are used now could be used in the ajax plug-in 
tags.  So if you are upgrading you'd just need to ensure that the 
plug-in is there.  I haven't checked lately, but I think there is quiet 
a difference from WW2 to Struts2 for the ajax tags (i.e. new attributes, 
new dojo version, new tags).
>
> Don
>
> Ian Roughley wrote:
>> The wrappers around the beans are there to provide accessors to new 
>> attributes needed by the ajax tags.  If we were to extract the tags 
>> into a separate taglib or library, I don't think we would need the 
>> wrappers.  The additionally required attributes would be contained on 
>> the new classes in the new library.  This would also remove the 
>> dependency of s2 on each ajax library we use (i.e. for dojo we need 
>> an additional attribute x & y, for prototype maybe we use y and add 
>> new attributes a & b).
>>
>> But I like the idea :)  It would also help with the more frequent 
>> dojo updates.
>>
>> /Ian
>>
>>
>>
>> Ted Husted wrote:
>>> Meanwhile, what about Don's suggestion that we keep the wrappers but
>>> drop the theme and put the tags into their own library or plugin? We'd
>>> need to do something like that first, regardless of where the code
>>> ultimately lives.
>>>
>>> -Ted.
>>>
>>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>>>> Probably a better integration in some places...but it would definitely
>>>> be worth considering not to duplicate what others are doing.
>>>>
>>>> musachy
>>>>
>>>> Don Brown wrote:
>>>> > Well, if there is an external project that already does 
>>>> everything we
>>>> > want, then why don't we just use them?  I'm all for minimizing
>>>> > duplication.  What value does having our own ajax tag library 
>>>> provide?
>>>> >
>>>> > Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)

[Don Brown <mr...@twdata.org>]

As much as I absolutely hate to say it, I think we need to resolve this 
ajax tag issue before 2.0 goes GA.  The AJAX support of Struts 2 gets so 
much attention by the community that to have a brittle, poorly supported 
feature that we hope to remove in the next release will only bring 
confusion and rejection of Struts 2 as a whole.

If we created a new tag library, our current tags should be able to be 
very much simplified as a lot of the attributes would go away.  The new 
tags would be much clearer and easier to pick up without having to 
explain themes and why certain attributes only work in certain situations.

On the other hand, ripping the ajax tags out would affect backwards 
compatibility.  Are a lot of users out there using these tags?  Could 
the migration be simple or would it involve too much effort?

Don

Ian Roughley wrote:
> The wrappers around the beans are there to provide accessors to new 
> attributes needed by the ajax tags.  If we were to extract the tags 
> into a separate taglib or library, I don't think we would need the 
> wrappers.  The additionally required attributes would be contained on 
> the new classes in the new library.  This would also remove the 
> dependency of s2 on each ajax library we use (i.e. for dojo we need an 
> additional attribute x & y, for prototype maybe we use y and add new 
> attributes a & b).
>
> But I like the idea :)  It would also help with the more frequent dojo 
> updates.
>
> /Ian
>
>
>
> Ted Husted wrote:
>> Meanwhile, what about Don's suggestion that we keep the wrappers but
>> drop the theme and put the tags into their own library or plugin? We'd
>> need to do something like that first, regardless of where the code
>> ultimately lives.
>>
>> -Ted.
>>
>> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>>> Probably a better integration in some places...but it would definitely
>>> be worth considering not to duplicate what others are doing.
>>>
>>> musachy
>>>
>>> Don Brown wrote:
>>> > Well, if there is an external project that already does everything we
>>> > want, then why don't we just use them?  I'm all for minimizing
>>> > duplication.  What value does having our own ajax tag library 
>>> provide?
>>> >
>>> > Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Ian Roughley <ia...@fdar.com>]

The wrappers around the beans are there to provide accessors to new 
attributes needed by the ajax tags.  If we were to extract the tags into 
a separate taglib or library, I don't think we would need the wrappers.  
The additionally required attributes would be contained on the new 
classes in the new library.  This would also remove the dependency of s2 
on each ajax library we use (i.e. for dojo we need an additional 
attribute x & y, for prototype maybe we use y and add new attributes a & b).

But I like the idea :)  It would also help with the more frequent dojo 
updates.

/Ian



Ted Husted wrote:
> Meanwhile, what about Don's suggestion that we keep the wrappers but
> drop the theme and put the tags into their own library or plugin? We'd
> need to do something like that first, regardless of where the code
> ultimately lives.
>
> -Ted.
>
> On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
>> Probably a better integration in some places...but it would definitely
>> be worth considering not to duplicate what others are doing.
>>
>> musachy
>>
>> Don Brown wrote:
>> > Well, if there is an external project that already does everything we
>> > want, then why don't we just use them?  I'm all for minimizing
>> > duplication.  What value does having our own ajax tag library provide?
>> >
>> > Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Ted Husted <hu...@apache.org>]

Meanwhile, what about Don's suggestion that we keep the wrappers but
drop the theme and put the tags into their own library or plugin? We'd
need to do something like that first, regardless of where the code
ultimately lives.

-Ted.

On 12/14/06, Musachy Barroso <mb...@wfscorp.com> wrote:
> Probably a better integration in some places...but it would definitely
> be worth considering not to duplicate what others are doing.
>
> musachy
>
> Don Brown wrote:
> > Well, if there is an external project that already does everything we
> > want, then why don't we just use them?  I'm all for minimizing
> > duplication.  What value does having our own ajax tag library provide?
> >
> > Don

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Musachy Barroso <mb...@wfscorp.com>]

Probably a better integration in some places...but it would definitely 
be worth considering not to duplicate what others are doing.

musachy

Don Brown wrote:
> Well, if there is an external project that already does everything we 
> want, then why don't we just use them?  I'm all for minimizing 
> duplication.  What value does having our own ajax tag library provide?
>
> Don
>
> Musachy Barroso wrote:
>> I didn't say it before, but in that I agree with you all, they could 
>> be in a plugin, I just think we should have them, somewhere. A 
>> separate project, I don't think it is a good idea, there are plenty 
>> of ajax projects out there, and we don't want to implement a lot of 
>> tags (that javascript is driving me nuts already :) ).
>>
>> musachy
>> Don Brown wrote:
>>> I agree with both of you :)  On one hand, I hate to maintain code in 
>>> Struts that doesn't provide any real added value and saps already 
>>> precious resources and time.  On the other hand, I want to make 
>>> Struts immediately useful and having a powerful tag library is key.
>>>
>>> I'm wondering if having ajax wrapping tags are ok, but perhaps 
>>> reusing the "theme" feature is a bad idea and these tags should be 
>>> given their own library.  This library could, in fact, be a plugin 
>>> or even an external project that we bundle with Struts 2 much like 
>>> Spring or DWR.
>>>
>>> Don
>>>
>>> Musachy Barroso wrote:
>>>> I wouldn't agree to have tags for every Dojo widget, which would be 
>>>> insane, but keeping these few tags, can make life a lot easier for 
>>>> users who only want to add some "ajax-behavior" here and there in 
>>>> their applications.
>>>>
>>>> musachy
>>>>
>>>> Ian Roughley wrote:
>>>>> This has been my concern for some time now... especially with the 
>>>>> dojo / ajax tags.  What we seem to be doing is simply wrapping the 
>>>>> dojo tag with a s2 tag - providing ways to access the dojo 
>>>>> specific attributes.
>>>>> There are then additional issues - such as the dojo code releasing 
>>>>> more often then s2 (3 releases I think since ww became s2); not 
>>>>> all the attributes of the dojo tag in the s2 taglib; and not all 
>>>>> the functionality included (especially advanced functionality).  
>>>>> If users then want to upgrade the dojo library themselves, they 
>>>>> are forced to deal with possible conflicts - either running 2 
>>>>> different version (one in s2 and another); using one version and 
>>>>> possibly breaking the s2 tags; migrating all the tags from s2 
>>>>> taglibs to pure dojo; or simply becoming frustrated and not using 
>>>>> the features (which I think is the worse situation).
>>>>>
>>>>> Perhaps this is best left to the dojo html with s:property taglibs 
>>>>> for values?
>>>>>
>>>>> /Ian
>>>>>
>>>>>
>>>>> Don Brown wrote:
>>>>>> The question is do we want to create one Struts tag library that 
>>>>>> does everything, or focus on tags that require close ties with 
>>>>>> our framework?  While I like the idea of providing more features 
>>>>>> and tags to our users, I wonder if within Struts is the best 
>>>>>> place to host it...
>>>>>>
>>>>>> Don
>>>>>>
>>>>>> Ted Husted wrote:
>>>>>>> I know I've implemented paging a dozen different ways, and 
>>>>>>> reducing to
>>>>>>> a tag of our own sounds like a good idea. Ditto with sorted 
>>>>>>> tables. If
>>>>>>> you wanted to contribute the tags, the thing to do would be to 
>>>>>>> file a
>>>>>>> CLA and open a JIRA ticket with the code attached,.
>>>>>>>
>>>>>>> * http://apache.org/licenses/#clas
>>>>>>>
>>>>>>> -Ted.
>>>>>>>
>>>>>>> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>>>>>>>> Hello,
>>>>>>>> I've been working with webwork since June.  My company migrated 
>>>>>>>> from a
>>>>>>>> home-grown webframework to webwork and it has been a very good
>>>>>>>> experience.  I'm excited to see how struts2 can improve on an 
>>>>>>>> already
>>>>>>>> top-notch framework.
>>>>>>>>
>>>>>>>> In the process of integrating webwork with our software, I 
>>>>>>>> implemented
>>>>>>>> several UI tags that probably could be used on other projects.  
>>>>>>>> I wanted
>>>>>>>> to get a feel for whether there was a desire to add these tags 
>>>>>>>> to the
>>>>>>>> core struts project.  Although there are other open source tags 
>>>>>>>> that
>>>>>>>> implement this functionality, we leverage the template based 
>>>>>>>> nature of
>>>>>>>> the UI tags very heavily and wanted tags that allowed us this 
>>>>>>>> type of
>>>>>>>> customization.
>>>>>>>>
>>>>>>>> Pager - the pager tag is used to display a small pager display 
>>>>>>>> to allow
>>>>>>>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This 
>>>>>>>> is used on
>>>>>>>> almost all the pages where we have lists of data.
>>>>>>>>
>>>>>>>> SortColumn - the sort column tag displays the column name, the 
>>>>>>>> current
>>>>>>>> sort direction and is hyperlinked so that the sort 
>>>>>>>> direction/selected
>>>>>>>> sort column can be changed (e.g. Name ^ or Name v)
>>>>>>>>
>>>>>>>> So, my question is: Is there any interest in adding these kinds 
>>>>>>>> of tags
>>>>>>>> to the core struts tag library, or should these be separate?  I 
>>>>>>>> would
>>>>>>>> think there would be enough other projects out there that would 
>>>>>>>> need
>>>>>>>> these types of tags to warrant it, however, I've been doing only
>>>>>>>> database apps for the last 2 years, so my perspective may be 
>>>>>>>> skewed a bit.
>>>>>>>> Thanks,
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------- 
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Don Brown <mr...@twdata.org>]

Well, if there is an external project that already does everything we 
want, then why don't we just use them?  I'm all for minimizing 
duplication.  What value does having our own ajax tag library provide?

Don

Musachy Barroso wrote:
> I didn't say it before, but in that I agree with you all, they could 
> be in a plugin, I just think we should have them, somewhere. A 
> separate project, I don't think it is a good idea, there are plenty of 
> ajax projects out there, and we don't want to implement a lot of tags 
> (that javascript is driving me nuts already :) ).
>
> musachy
> Don Brown wrote:
>> I agree with both of you :)  On one hand, I hate to maintain code in 
>> Struts that doesn't provide any real added value and saps already 
>> precious resources and time.  On the other hand, I want to make 
>> Struts immediately useful and having a powerful tag library is key.
>>
>> I'm wondering if having ajax wrapping tags are ok, but perhaps 
>> reusing the "theme" feature is a bad idea and these tags should be 
>> given their own library.  This library could, in fact, be a plugin or 
>> even an external project that we bundle with Struts 2 much like 
>> Spring or DWR.
>>
>> Don
>>
>> Musachy Barroso wrote:
>>> I wouldn't agree to have tags for every Dojo widget, which would be 
>>> insane, but keeping these few tags, can make life a lot easier for 
>>> users who only want to add some "ajax-behavior" here and there in 
>>> their applications.
>>>
>>> musachy
>>>
>>> Ian Roughley wrote:
>>>> This has been my concern for some time now... especially with the 
>>>> dojo / ajax tags.  What we seem to be doing is simply wrapping the 
>>>> dojo tag with a s2 tag - providing ways to access the dojo specific 
>>>> attributes.
>>>> There are then additional issues - such as the dojo code releasing 
>>>> more often then s2 (3 releases I think since ww became s2); not all 
>>>> the attributes of the dojo tag in the s2 taglib; and not all the 
>>>> functionality included (especially advanced functionality).  If 
>>>> users then want to upgrade the dojo library themselves, they are 
>>>> forced to deal with possible conflicts - either running 2 different 
>>>> version (one in s2 and another); using one version and possibly 
>>>> breaking the s2 tags; migrating all the tags from s2 taglibs to 
>>>> pure dojo; or simply becoming frustrated and not using the features 
>>>> (which I think is the worse situation).
>>>>
>>>> Perhaps this is best left to the dojo html with s:property taglibs 
>>>> for values?
>>>>
>>>> /Ian
>>>>
>>>>
>>>> Don Brown wrote:
>>>>> The question is do we want to create one Struts tag library that 
>>>>> does everything, or focus on tags that require close ties with our 
>>>>> framework?  While I like the idea of providing more features and 
>>>>> tags to our users, I wonder if within Struts is the best place to 
>>>>> host it...
>>>>>
>>>>> Don
>>>>>
>>>>> Ted Husted wrote:
>>>>>> I know I've implemented paging a dozen different ways, and 
>>>>>> reducing to
>>>>>> a tag of our own sounds like a good idea. Ditto with sorted 
>>>>>> tables. If
>>>>>> you wanted to contribute the tags, the thing to do would be to 
>>>>>> file a
>>>>>> CLA and open a JIRA ticket with the code attached,.
>>>>>>
>>>>>> * http://apache.org/licenses/#clas
>>>>>>
>>>>>> -Ted.
>>>>>>
>>>>>> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>>>>>>> Hello,
>>>>>>> I've been working with webwork since June.  My company migrated 
>>>>>>> from a
>>>>>>> home-grown webframework to webwork and it has been a very good
>>>>>>> experience.  I'm excited to see how struts2 can improve on an 
>>>>>>> already
>>>>>>> top-notch framework.
>>>>>>>
>>>>>>> In the process of integrating webwork with our software, I 
>>>>>>> implemented
>>>>>>> several UI tags that probably could be used on other projects.  
>>>>>>> I wanted
>>>>>>> to get a feel for whether there was a desire to add these tags 
>>>>>>> to the
>>>>>>> core struts project.  Although there are other open source tags 
>>>>>>> that
>>>>>>> implement this functionality, we leverage the template based 
>>>>>>> nature of
>>>>>>> the UI tags very heavily and wanted tags that allowed us this 
>>>>>>> type of
>>>>>>> customization.
>>>>>>>
>>>>>>> Pager - the pager tag is used to display a small pager display 
>>>>>>> to allow
>>>>>>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is 
>>>>>>> used on
>>>>>>> almost all the pages where we have lists of data.
>>>>>>>
>>>>>>> SortColumn - the sort column tag displays the column name, the 
>>>>>>> current
>>>>>>> sort direction and is hyperlinked so that the sort 
>>>>>>> direction/selected
>>>>>>> sort column can be changed (e.g. Name ^ or Name v)
>>>>>>>
>>>>>>> So, my question is: Is there any interest in adding these kinds 
>>>>>>> of tags
>>>>>>> to the core struts tag library, or should these be separate?  I 
>>>>>>> would
>>>>>>> think there would be enough other projects out there that would 
>>>>>>> need
>>>>>>> these types of tags to warrant it, however, I've been doing only
>>>>>>> database apps for the last 2 years, so my perspective may be 
>>>>>>> skewed a bit.
>>>>>>> Thanks,
>>>>>>> Tom
>>>>>>>
>>>>>>> --------------------------------------------------------------------- 
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Musachy Barroso <mb...@wfscorp.com>]

I didn't say it before, but in that I agree with you all, they could be 
in a plugin, I just think we should have them, somewhere. A separate 
project, I don't think it is a good idea, there are plenty of ajax 
projects out there, and we don't want to implement a lot of tags (that 
javascript is driving me nuts already :) ).

musachy
Don Brown wrote:
> I agree with both of you :)  On one hand, I hate to maintain code in 
> Struts that doesn't provide any real added value and saps already 
> precious resources and time.  On the other hand, I want to make Struts 
> immediately useful and having a powerful tag library is key.
>
> I'm wondering if having ajax wrapping tags are ok, but perhaps reusing 
> the "theme" feature is a bad idea and these tags should be given their 
> own library.  This library could, in fact, be a plugin or even an 
> external project that we bundle with Struts 2 much like Spring or DWR.
>
> Don
>
> Musachy Barroso wrote:
>> I wouldn't agree to have tags for every Dojo widget, which would be 
>> insane, but keeping these few tags, can make life a lot easier for 
>> users who only want to add some "ajax-behavior" here and there in 
>> their applications.
>>
>> musachy
>>
>> Ian Roughley wrote:
>>> This has been my concern for some time now... especially with the 
>>> dojo / ajax tags.  What we seem to be doing is simply wrapping the 
>>> dojo tag with a s2 tag - providing ways to access the dojo specific 
>>> attributes.
>>> There are then additional issues - such as the dojo code releasing 
>>> more often then s2 (3 releases I think since ww became s2); not all 
>>> the attributes of the dojo tag in the s2 taglib; and not all the 
>>> functionality included (especially advanced functionality).  If 
>>> users then want to upgrade the dojo library themselves, they are 
>>> forced to deal with possible conflicts - either running 2 different 
>>> version (one in s2 and another); using one version and possibly 
>>> breaking the s2 tags; migrating all the tags from s2 taglibs to pure 
>>> dojo; or simply becoming frustrated and not using the features 
>>> (which I think is the worse situation).
>>>
>>> Perhaps this is best left to the dojo html with s:property taglibs 
>>> for values?
>>>
>>> /Ian
>>>
>>>
>>> Don Brown wrote:
>>>> The question is do we want to create one Struts tag library that 
>>>> does everything, or focus on tags that require close ties with our 
>>>> framework?  While I like the idea of providing more features and 
>>>> tags to our users, I wonder if within Struts is the best place to 
>>>> host it...
>>>>
>>>> Don
>>>>
>>>> Ted Husted wrote:
>>>>> I know I've implemented paging a dozen different ways, and 
>>>>> reducing to
>>>>> a tag of our own sounds like a good idea. Ditto with sorted 
>>>>> tables. If
>>>>> you wanted to contribute the tags, the thing to do would be to file a
>>>>> CLA and open a JIRA ticket with the code attached,.
>>>>>
>>>>> * http://apache.org/licenses/#clas
>>>>>
>>>>> -Ted.
>>>>>
>>>>> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>>>>>> Hello,
>>>>>> I've been working with webwork since June.  My company migrated 
>>>>>> from a
>>>>>> home-grown webframework to webwork and it has been a very good
>>>>>> experience.  I'm excited to see how struts2 can improve on an 
>>>>>> already
>>>>>> top-notch framework.
>>>>>>
>>>>>> In the process of integrating webwork with our software, I 
>>>>>> implemented
>>>>>> several UI tags that probably could be used on other projects.  I 
>>>>>> wanted
>>>>>> to get a feel for whether there was a desire to add these tags to 
>>>>>> the
>>>>>> core struts project.  Although there are other open source tags that
>>>>>> implement this functionality, we leverage the template based 
>>>>>> nature of
>>>>>> the UI tags very heavily and wanted tags that allowed us this 
>>>>>> type of
>>>>>> customization.
>>>>>>
>>>>>> Pager - the pager tag is used to display a small pager display to 
>>>>>> allow
>>>>>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is 
>>>>>> used on
>>>>>> almost all the pages where we have lists of data.
>>>>>>
>>>>>> SortColumn - the sort column tag displays the column name, the 
>>>>>> current
>>>>>> sort direction and is hyperlinked so that the sort 
>>>>>> direction/selected
>>>>>> sort column can be changed (e.g. Name ^ or Name v)
>>>>>>
>>>>>> So, my question is: Is there any interest in adding these kinds 
>>>>>> of tags
>>>>>> to the core struts tag library, or should these be separate?  I 
>>>>>> would
>>>>>> think there would be enough other projects out there that would need
>>>>>> these types of tags to warrant it, however, I've been doing only
>>>>>> database apps for the last 2 years, so my perspective may be 
>>>>>> skewed a bit.
>>>>>> Thanks,
>>>>>> Tom
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Don Brown <mr...@twdata.org>]

I agree with both of you :)  On one hand, I hate to maintain code in 
Struts that doesn't provide any real added value and saps already 
precious resources and time.  On the other hand, I want to make Struts 
immediately useful and having a powerful tag library is key.

I'm wondering if having ajax wrapping tags are ok, but perhaps reusing 
the "theme" feature is a bad idea and these tags should be given their 
own library.  This library could, in fact, be a plugin or even an 
external project that we bundle with Struts 2 much like Spring or DWR.

Don

Musachy Barroso wrote:
> I wouldn't agree to have tags for every Dojo widget, which would be 
> insane, but keeping these few tags, can make life a lot easier for 
> users who only want to add some "ajax-behavior" here and there in 
> their applications.
>
> musachy
>
> Ian Roughley wrote:
>> This has been my concern for some time now... especially with the 
>> dojo / ajax tags.  What we seem to be doing is simply wrapping the 
>> dojo tag with a s2 tag - providing ways to access the dojo specific 
>> attributes.
>> There are then additional issues - such as the dojo code releasing 
>> more often then s2 (3 releases I think since ww became s2); not all 
>> the attributes of the dojo tag in the s2 taglib; and not all the 
>> functionality included (especially advanced functionality).  If users 
>> then want to upgrade the dojo library themselves, they are forced to 
>> deal with possible conflicts - either running 2 different version 
>> (one in s2 and another); using one version and possibly breaking the 
>> s2 tags; migrating all the tags from s2 taglibs to pure dojo; or 
>> simply becoming frustrated and not using the features (which I think 
>> is the worse situation).
>>
>> Perhaps this is best left to the dojo html with s:property taglibs 
>> for values?
>>
>> /Ian
>>
>>
>> Don Brown wrote:
>>> The question is do we want to create one Struts tag library that 
>>> does everything, or focus on tags that require close ties with our 
>>> framework?  While I like the idea of providing more features and 
>>> tags to our users, I wonder if within Struts is the best place to 
>>> host it...
>>>
>>> Don
>>>
>>> Ted Husted wrote:
>>>> I know I've implemented paging a dozen different ways, and reducing to
>>>> a tag of our own sounds like a good idea. Ditto with sorted tables. If
>>>> you wanted to contribute the tags, the thing to do would be to file a
>>>> CLA and open a JIRA ticket with the code attached,.
>>>>
>>>> * http://apache.org/licenses/#clas
>>>>
>>>> -Ted.
>>>>
>>>> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>>>>> Hello,
>>>>> I've been working with webwork since June.  My company migrated 
>>>>> from a
>>>>> home-grown webframework to webwork and it has been a very good
>>>>> experience.  I'm excited to see how struts2 can improve on an already
>>>>> top-notch framework.
>>>>>
>>>>> In the process of integrating webwork with our software, I 
>>>>> implemented
>>>>> several UI tags that probably could be used on other projects.  I 
>>>>> wanted
>>>>> to get a feel for whether there was a desire to add these tags to the
>>>>> core struts project.  Although there are other open source tags that
>>>>> implement this functionality, we leverage the template based 
>>>>> nature of
>>>>> the UI tags very heavily and wanted tags that allowed us this type of
>>>>> customization.
>>>>>
>>>>> Pager - the pager tag is used to display a small pager display to 
>>>>> allow
>>>>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is 
>>>>> used on
>>>>> almost all the pages where we have lists of data.
>>>>>
>>>>> SortColumn - the sort column tag displays the column name, the 
>>>>> current
>>>>> sort direction and is hyperlinked so that the sort direction/selected
>>>>> sort column can be changed (e.g. Name ^ or Name v)
>>>>>
>>>>> So, my question is: Is there any interest in adding these kinds of 
>>>>> tags
>>>>> to the core struts tag library, or should these be separate?  I would
>>>>> think there would be enough other projects out there that would need
>>>>> these types of tags to warrant it, however, I've been doing only
>>>>> database apps for the last 2 years, so my perspective may be 
>>>>> skewed a bit.
>>>>> Thanks,
>>>>> Tom
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Musachy Barroso <mb...@wfscorp.com>]

 I wouldn't agree to have tags for every Dojo widget, which would be 
insane, but keeping these few tags, can make life a lot easier for users 
who only want to add some "ajax-behavior" here and there in their 
applications.

musachy

Ian Roughley wrote:
> This has been my concern for some time now... especially with the dojo 
> / ajax tags.  What we seem to be doing is simply wrapping the dojo tag 
> with a s2 tag - providing ways to access the dojo specific attributes.
> There are then additional issues - such as the dojo code releasing 
> more often then s2 (3 releases I think since ww became s2); not all 
> the attributes of the dojo tag in the s2 taglib; and not all the 
> functionality included (especially advanced functionality).  If users 
> then want to upgrade the dojo library themselves, they are forced to 
> deal with possible conflicts - either running 2 different version (one 
> in s2 and another); using one version and possibly breaking the s2 
> tags; migrating all the tags from s2 taglibs to pure dojo; or simply 
> becoming frustrated and not using the features (which I think is the 
> worse situation).
>
> Perhaps this is best left to the dojo html with s:property taglibs for 
> values?
>
> /Ian
>
>
> Don Brown wrote:
>> The question is do we want to create one Struts tag library that does 
>> everything, or focus on tags that require close ties with our 
>> framework?  While I like the idea of providing more features and tags 
>> to our users, I wonder if within Struts is the best place to host it...
>>
>> Don
>>
>> Ted Husted wrote:
>>> I know I've implemented paging a dozen different ways, and reducing to
>>> a tag of our own sounds like a good idea. Ditto with sorted tables. If
>>> you wanted to contribute the tags, the thing to do would be to file a
>>> CLA and open a JIRA ticket with the code attached,.
>>>
>>> * http://apache.org/licenses/#clas
>>>
>>> -Ted.
>>>
>>> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>>>> Hello,
>>>> I've been working with webwork since June.  My company migrated from a
>>>> home-grown webframework to webwork and it has been a very good
>>>> experience.  I'm excited to see how struts2 can improve on an already
>>>> top-notch framework.
>>>>
>>>> In the process of integrating webwork with our software, I implemented
>>>> several UI tags that probably could be used on other projects.  I 
>>>> wanted
>>>> to get a feel for whether there was a desire to add these tags to the
>>>> core struts project.  Although there are other open source tags that
>>>> implement this functionality, we leverage the template based nature of
>>>> the UI tags very heavily and wanted tags that allowed us this type of
>>>> customization.
>>>>
>>>> Pager - the pager tag is used to display a small pager display to 
>>>> allow
>>>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is 
>>>> used on
>>>> almost all the pages where we have lists of data.
>>>>
>>>> SortColumn - the sort column tag displays the column name, the current
>>>> sort direction and is hyperlinked so that the sort direction/selected
>>>> sort column can be changed (e.g. Name ^ or Name v)
>>>>
>>>> So, my question is: Is there any interest in adding these kinds of 
>>>> tags
>>>> to the core struts tag library, or should these be separate?  I would
>>>> think there would be enough other projects out there that would need
>>>> these types of tags to warrant it, however, I've been doing only
>>>> database apps for the last 2 years, so my perspective may be skewed 
>>>> a bit.
>>>> Thanks,
>>>> Tom
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Ian Roughley <ia...@fdar.com>]

This has been my concern for some time now... especially with the dojo / 
ajax tags.  What we seem to be doing is simply wrapping the dojo tag 
with a s2 tag - providing ways to access the dojo specific attributes. 

There are then additional issues - such as the dojo code releasing more 
often then s2 (3 releases I think since ww became s2); not all the 
attributes of the dojo tag in the s2 taglib; and not all the 
functionality included (especially advanced functionality).  If users 
then want to upgrade the dojo library themselves, they are forced to 
deal with possible conflicts - either running 2 different version (one 
in s2 and another); using one version and possibly breaking the s2 tags; 
migrating all the tags from s2 taglibs to pure dojo; or simply becoming 
frustrated and not using the features (which I think is the worse 
situation).

Perhaps this is best left to the dojo html with s:property taglibs for 
values?

/Ian


Don Brown wrote:
> The question is do we want to create one Struts tag library that does 
> everything, or focus on tags that require close ties with our 
> framework?  While I like the idea of providing more features and tags 
> to our users, I wonder if within Struts is the best place to host it...
>
> Don
>
> Ted Husted wrote:
>> I know I've implemented paging a dozen different ways, and reducing to
>> a tag of our own sounds like a good idea. Ditto with sorted tables. If
>> you wanted to contribute the tags, the thing to do would be to file a
>> CLA and open a JIRA ticket with the code attached,.
>>
>> * http://apache.org/licenses/#clas
>>
>> -Ted.
>>
>> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>>> Hello,
>>> I've been working with webwork since June.  My company migrated from a
>>> home-grown webframework to webwork and it has been a very good
>>> experience.  I'm excited to see how struts2 can improve on an already
>>> top-notch framework.
>>>
>>> In the process of integrating webwork with our software, I implemented
>>> several UI tags that probably could be used on other projects.  I 
>>> wanted
>>> to get a feel for whether there was a desire to add these tags to the
>>> core struts project.  Although there are other open source tags that
>>> implement this functionality, we leverage the template based nature of
>>> the UI tags very heavily and wanted tags that allowed us this type of
>>> customization.
>>>
>>> Pager - the pager tag is used to display a small pager display to allow
>>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is 
>>> used on
>>> almost all the pages where we have lists of data.
>>>
>>> SortColumn - the sort column tag displays the column name, the current
>>> sort direction and is hyperlinked so that the sort direction/selected
>>> sort column can be changed (e.g. Name ^ or Name v)
>>>
>>> So, my question is: Is there any interest in adding these kinds of tags
>>> to the core struts tag library, or should these be separate?  I would
>>> think there would be enough other projects out there that would need
>>> these types of tags to warrant it, however, I've been doing only
>>> database apps for the last 2 years, so my perspective may be skewed 
>>> a bit.
>>> Thanks,
>>> Tom
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Don Brown <mr...@twdata.org>]

The question is do we want to create one Struts tag library that does 
everything, or focus on tags that require close ties with our 
framework?  While I like the idea of providing more features and tags to 
our users, I wonder if within Struts is the best place to host it...

Don

Ted Husted wrote:
> I know I've implemented paging a dozen different ways, and reducing to
> a tag of our own sounds like a good idea. Ditto with sorted tables. If
> you wanted to contribute the tags, the thing to do would be to file a
> CLA and open a JIRA ticket with the code attached,.
>
> * http://apache.org/licenses/#clas
>
> -Ted.
>
> On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
>> Hello,
>> I've been working with webwork since June.  My company migrated from a
>> home-grown webframework to webwork and it has been a very good
>> experience.  I'm excited to see how struts2 can improve on an already
>> top-notch framework.
>>
>> In the process of integrating webwork with our software, I implemented
>> several UI tags that probably could be used on other projects.  I wanted
>> to get a feel for whether there was a desire to add these tags to the
>> core struts project.  Although there are other open source tags that
>> implement this functionality, we leverage the template based nature of
>> the UI tags very heavily and wanted tags that allowed us this type of
>> customization.
>>
>> Pager - the pager tag is used to display a small pager display to allow
>> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is used on
>> almost all the pages where we have lists of data.
>>
>> SortColumn - the sort column tag displays the column name, the current
>> sort direction and is hyperlinked so that the sort direction/selected
>> sort column can be changed (e.g. Name ^ or Name v)
>>
>> So, my question is: Is there any interest in adding these kinds of tags
>> to the core struts tag library, or should these be separate?  I would
>> think there would be enough other projects out there that would need
>> these types of tags to warrant it, however, I've been doing only
>> database apps for the last 2 years, so my perspective may be skewed a 
>> bit.
>> Thanks,
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Additional UI tags

[Ted Husted <hu...@apache.org>]

I know I've implemented paging a dozen different ways, and reducing to
a tag of our own sounds like a good idea. Ditto with sorted tables. If
 you wanted to contribute the tags, the thing to do would be to file a
CLA and open a JIRA ticket with the code attached,.

* http://apache.org/licenses/#clas

-Ted.

On 12/10/06, Tom Schneider <sc...@gmail.com> wrote:
> Hello,
> I've been working with webwork since June.  My company migrated from a
> home-grown webframework to webwork and it has been a very good
> experience.  I'm excited to see how struts2 can improve on an already
> top-notch framework.
>
> In the process of integrating webwork with our software, I implemented
> several UI tags that probably could be used on other projects.  I wanted
> to get a feel for whether there was a desire to add these tags to the
> core struts project.  Although there are other open source tags that
> implement this functionality, we leverage the template based nature of
> the UI tags very heavily and wanted tags that allowed us this type of
> customization.
>
> Pager - the pager tag is used to display a small pager display to allow
> pagination navigation. (e.g. <<  <  1 to 6 of 30 >  >>)  This is used on
> almost all the pages where we have lists of data.
>
> SortColumn - the sort column tag displays the column name, the current
> sort direction and is hyperlinked so that the sort direction/selected
> sort column can be changed (e.g. Name ^ or Name v)
>
> So, my question is: Is there any interest in adding these kinds of tags
> to the core struts tag library, or should these be separate?  I would
> think there would be enough other projects out there that would need
> these types of tags to warrant it, however, I've been doing only
> database apps for the last 2 years, so my perspective may be skewed a bit.
> Thanks,
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


-- 
HTH, Ted.
* http://www.husted.com/struts/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org