On 12/19/06, Don Brown <[EMAIL PROTECTED]> 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 <[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]
