Ok I added a page to the wiki with what I think we have discussed/agreed so far, and the things we need to do:
http://cwiki.apache.org/confluence/display/S2WIKI/JQuery+Ajax+Tags+Plugin+Proposal So far we all agree that we need a small set of tags that covers the simple uses cases, and that it is not supposed to expose all the features of the underlying framework. My answer to: why jquery? JQuery has proven to be very reliable, small and stable, there is plenty of documentation, but above all that, there are several of us using it on our current jobs, which gives it a good chance to be properly maintained. Also, we were already working ("we" as in Wes ;)) on a JQuery plugin. Feel free to fill in the wiki with your ideas and comments. musachy On Tue, Jul 28, 2009 at 7:41 PM, Martin Cooper<mart...@apache.org> wrote: > I'm here, and I've been following along. I just haven't had time to > consolidate my thoughts until now. > > First of all, I hope everyone recognises that it's by no means my call; it's > the team's call. > > The subject of Ajax tags in Struts 2 has been hotly discussed over a period > of years. At different points in time, different bases for such tags have > been the hot favourite, from custom code through Dojo to jQuery, with a few > other stops in between. Some of the work has happened here and some has > happened elsewhere. > > From my perspective, it is critical, in adopting any set of Ajax tags as a > baked-in part of Struts, that we, as a team, are fully convinced (a) that > the underlying toolkit is not just the flavour of the month and will last > for years to come, and (b) that we have a sufficient body of developers > committed to making it work today and keeping it working years from now. And > I do mean years here. Certainly the world will change, and the world of > highly interactive web apps will change. But think about this: Struts 1 was > first released 9 (nine) years ago, and many thousands of web apps that were > built on it are still running, and being maintained, today. I'm sure we > would all like to have that level of success, and longevity, with Struts 2. > It takes commitment, though. > > I do take issue with a few statements that have been made in this thread > about Ajax toolkits. Rene said that we can consider Dojo "the biggest > loser". Can we really consider a toolkit that has seen corporate adoption > from the likes of IBM, Sun, AOL, Google, Nexaweb, and numerous others, "the > biggest loser"? Some people here may not like to work with it, but Dojo is > one of the biggest success stories in the Ajax world. That's not to say that > jQuery has not had its successes - and, as Wes points out, has seen adoption > by Microsoft - but jQuery is still a long way from "the" Ajax framework that > Rene asserts. > > That said, the above is not an argument against the adoption of jQuery as > the basis for Struts 2 Ajax tags. It's merely my attempt to bring us down to > earth a little bit in our enthusiasm to jump on jQuery and ditch Dojo. Each > has its merits, as do other alternatives. > > So, assuming the general concensus is to move forward with integration of > Johannes' tags, what are the next steps? > > 1) Musachy hit the nail on the head when he said "I would like for us to > define some strategy for this". It's crucial that we define, up front, where > we want to go with this. What should the Ajax tags include? What should they > specifically _not_ include, which is at least as important? Do we still > believe that what we want is a set of simple tags and nothing more? If not, > why not? How much coupling - that is, loose or tight - do we want to live > with? It would be great to see some (more) discussion of this kind of thing > up front, and perhaps the concensus documented on the wiki for all to see > (and abide by). > > 2) Once we've agreed on the major points from #1 above, we can take a > clear-headed look at what Johannes has done and assess how well it meets > those needs. What would need to be added? What should be removed, to keep it > streamlined to our objectives? We should be sure that we're not jumping on > the "cool" factor, and have something that forms the basis for our needs. > > 3) If we're going to bring Johannes' code into Struts itself, we need an > iCLA, and personally I would prefer to see us use the IP Clearance process > to make sure we're all squared away. Johannes' iCLA is on file already. The > IP Clearance process is intended to be straightforward and quick, so it > should not be an issue. > > 4) Musachy does raise an excellent question regarding commit rights and the > sandbox. We have not hit this exact case before. Obviously we'll need to > figure this one out. > > One final point: I recognise and understand the enthusiasm that's behind the > "let's get it in here now!" sentiment, but really, we're not in a huge big > hurry. Let's take the time we need to think through where we want to take > this, before we head of down the road with it. A week or two here or there > won't make any difference in the long run, but poor decisions will. > > -- > Martin Cooper > > > On Tue, Jul 28, 2009 at 6:22 AM, Wes Wannemacher <w...@wantii.com> wrote: > >> On Tue, Jul 28, 2009 at 7:29 AM, Rainer Hermanns<herma...@aixcept.de> >> wrote: >> [snip] >> > Here is my +1, but maybe we should call a formal vote on this? >> > >> >> I don't think we need a vote, the only person (voice of reason) so far >> was Martin. I would say that if you're listening Martin, chime in and >> let us know if we've convinced you yet. Or, let us know which concerns >> you want addressed before moving forward. >> >> -Wes >> >> -- >> Wes Wannemacher >> >> Head Engineer, WanTii, Inc. >> Need Training? Struts, Spring, Maven, Tomcat... >> Ask me for a quote! >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
