Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 36881 invoked from network); 23 Jul 2008 03:30:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Jul 2008 03:30:40 -0000 Received: (qmail 30815 invoked by uid 500); 23 Jul 2008 03:30:34 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 30798 invoked by uid 500); 23 Jul 2008 03:30:34 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 30787 invoked by uid 99); 23 Jul 2008 03:30:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jul 2008 20:30:34 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [216.227.215.170] (HELO chiron.lunarpages.com) (216.227.215.170) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Jul 2008 03:29:37 +0000 Received: from c-68-39-41-145.hsd1.pa.comcast.net ([68.39.41.145] helo=[192.168.123.198]) by chiron.lunarpages.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KLV3C-0000Rc-CV for dev@struts.apache.org; Tue, 22 Jul 2008 20:30:02 -0700 Message-ID: <4886A5A8.5000500@omnytex.com> Date: Tue, 22 Jul 2008 23:29:44 -0400 From: "Frank W. Zammetti" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Struts Developers List Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin References: <488544CB.7040102@blueskyminds.com.au> <8b3ce3790807221618w2854dfel9c541a36fecf3cf1@mail.gmail.com> In-Reply-To: <8b3ce3790807221618w2854dfel9c541a36fecf3cf1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chiron.lunarpages.com X-AntiAbuse: Original Domain - struts.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - omnytex.com X-Virus-Checked: Checked by ClamAV on apache.org 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 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: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org