struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Wilmoth <jonwilm...@yahoo.com>
Subject Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)
Date Tue, 19 Dec 2006 17:27:38 GMT
As a user, I'm very much looking forward to the dojo 0.4.x calendar widget (or something equally
aesthetic/functional) that was previously discussed as being tied to the date input tag(s).
 However that's accomplished... I just thought you may want to hear from a user's perspective.

----- Original Message ----
From: Don Brown <mrdon@twdata.org>
To: Struts Developers List <dev@struts.apache.org>
Sent: Tuesday, December 19, 2006 8:55:22 AM
Subject: Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)


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 <mbarroso@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


Mime
View raw message