Frank W. Zammetti
Tue, 22 Jul 2008 20:30:37 -0700
Not to toot my own horn or anything... but, what the heck :) ... speaking as someone who pioneered the whole "AJAX via taglib" approach (if it wasn't first, it was definitely *one of* the first, but for those that maybe haven't been around Struts as long as others, AjaxParts Taglib, or APT, was originally an enhanced version of the S1 HTML taglib that I created in early 2005)... I have a strong opinion that it's a good approach for many users.
Having a simple taglib-based approach to do some of the more common AJAX-y things, maybe some widgets here and there too, means that Java developers can leverage their existing skills without having to take the plunge into heavy client-side development, which I can say from the experience of mentoring some junior-level teams can be a very difficult hill to climb, regardless of what whiz-bang library you choose to use to try and make it easier. The very nature of Javascript, for many Java developers, is a difficult leap to make.
If the question is should the plugin be deprecated *without a replacement ready day one*, my opinion is that's a bad idea. Whether the current plugin is the right answer or not, I think it's better than nothing. Especially for those developers who aren't ready to make the leap to heavy client-side coding as many of us have done, a taglib-based approach is a godsend. I know this because while APT may not have the largest user community around, we have a very happy community, based on the feedback we get. Clearly the tag-based approach is something many developers very much want and like, and it's something that I think is a pretty attractive feature of S2. Losing it, even temporarily, would hurt I think, if in no other way than perception.
Even if there's no one ready, willing and able to do the work to address the shortcomings of the plugin, I don't think that's a reason to deprecate it. It may be fair to update some documentation to say something along the lines of "use at your own risk", whatever text reflects the true state of it, but beyond that I think it would be a step backwards for Struts, if in no other way than perception, to lose this capability, even if only briefly.
FrankP.S. - Ted, I see you're doing your TAE presentation again this year... I'll be attending again as well (although my proposal didn't get picked up, maybe next year), hope we can hook up at some point. Anyone else going to be in town?
-- Frank W. Zammetti Author of "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" for info: apress.com/book/search?searchterm=zammetti&act=search Java Web Parts - javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! My "look ma, I have a blog too!" blog: zammetti.com/blog Ted Husted wrote:
+1 for Musachy's suggestion, and I'm also at a point where I could help with the implementation. As to Ajax-enabling some of the tags, there are several tag-based Ajax libraries out there that we could look at embedding or emulating. In this case, we wouldn't be adopting a general-purpose Ajax library, but special-purpose scripts designed to be used with tags. * Ajax Tags - http://ajaxtags.sourceforge.net * Prize Tags - http://jenkov.com/prizetags/index.html * JSON-taglib - http://json-taglib.sourceforge.net/ * AjaxParts Taglib - http://javawebparts.sourceforge.net/ Has anyone had good or bad experiences with tag-based libraries like these? -Ted. On Mon, Jul 21, 2008 at 11:33 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:I am not sure about that approach. On one hand it is very "strutsish", in that is supports many ways of doing the same thing, and provides ways to extend what is provided, on the other hand, I think we should learn from other frameworks and just don't give users that many options, for they can be confusing, and frustrating when there is not enough documentation. Looking at ajax, and the ajax tags I think we have 2 kind of users: the power users, they won't use the ajax tag at all, unless they are doing something extremely simple. the beginners: they will use the ajax tags out of the box. When the beginners need to do something that is not provided by the tags out of the box, they start hacking away, and end up dumping the tags. So our target is the beginners, and they don't want customization, they just want to drop a few tags on their jsps and get it working. Based on that, I think we should either: don't provide any ajax tags at all, or just provide a very limited set of tags (like what Jeromy listed) with very little functionality to cover simple use cases, and use a reliable and simple framework for the implementation. Disregarding what path we take, I think it is fairly obvious that the Dojo plugin will end up unmaintained, that's why we should users know that we do not plan on upgrading from 0.4.3. musachy--------------------------------------------------------------------- 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]