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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
