Dojo 0.4.3 is old :-) I didn't know that. No one wants to move it to 1.x or wherever they are now?
Paul On Tue, Jul 22, 2008 at 10:29 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > As you could probably guess, I've had a lot of success with AjaxParts > Taglib ;) I've also had a lot of success with Dojo, ExtJS, ActiveWidgets, > dHTMLx and my personal favorite, DWR (I've found that DWR, plus > best-of-breed widgets is all the "framework" I need, which is why I haven't > posted here much lately, I haven't touched Struts in over a year myself). > (As to Dojo's popularity... well, it's definitely not a "de facto" > anything, that's for sure. May be some day, but not yet. Like Ted, I find > that as much as Dojo gets talked about, I don't hear from as many people > using it as the "press", so to speak, would suggest. It certainly *is* > popular, no question about that, but it seems like other libraries, most > notably jQuery, have kind of eclipsed it as the "place to be" in terms of > client-side libraries.) > > 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. > > Frank > > P.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] > >
