struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict" <pbened...@apache.org>
Subject Re: [PROPOSAL] Deprecate or remove Dojo plugin
Date Wed, 23 Jul 2008 03:44:28 GMT
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 <fzlists@omnytex.com>
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message