struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
Subject Re: [PROPOSAL] Deprecate or remove Dojo plugin
Date Wed, 23 Jul 2008 03:29:44 GMT
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 <musachy@gmail.com> 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


Mime
View raw message