struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musachy Barroso" <>
Subject Re: [PROPOSAL] Deprecate or remove Dojo plugin
Date Tue, 22 Jul 2008 03:33:37 GMT
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.


On Mon, Jul 21, 2008 at 10:24 PM, Jeromy Evans
<> wrote:
> Musachy Barroso wrote:
>> With all the problems/questions and time that the ajax tags have
>> caused, and not having any takers on porting to the latest Dojo
>> release. I would propose to deprecate, or even remove the Dojo plugin,
>> or at least let users know that we will not be upgrading to a newer
>> Dojo version anytime soon. I still like the idea of some *very* basic
>> tags to cover the most simple use cases, but I think Dojo was not the
>> right tool for the job.
> This is a BIG call. Although I share the sentiment, the ajax tags are an
> often-stated "great feature" of S2.  At least, that's what users comment
> until they need to do something sophisticated with the underlying library.
> I suggest an approach which is consistent with the above, should be in line
> with your thoughts Musachy and may even make Martin C happy:
> There are some core tags that must be provided/maintained by S2:
> - remote div
> - async submit of a form, targetting a div
> - async get (anchor tag), targetting a div
> We'd still supply those as tags as a minimum in say an "ajax plugin".
> Rather than bundle ajax libraries with S2, we would only bundle a few
> templates for integration of those tags with common libraries.  We use the
> existing theme's for this:
> eg.
>  <s:submit theme="dojo" href="form.action"/>
>  <s:submit theme="yui" href="form.action"/>
>  <s:submit theme="jquery" href="form.action"/>
> The templates implement the markup or inline javascript for a
> default/reference implementation.
> The template for the s:head tag would include the default scripts to setup
> the library.
>  <s:head theme="dojo"> will setup the bundled Dojo during the deprecated
> period
>  <s:head theme="jquery"> will include jquery dependencies from a
> default/overridden location (supplied by user).
> The s:head tag would be optional, but the user will be responsible for
> ensuring the library is available.
> Library-specific extensions for the tags would be specified via dynamic
> attributes only.
> All other dojo widget tags would be deprecated (tabbedPanel, autocompleter).
> Ajax validation and client-side validation also deserve some discussion
> later.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

"Hey you! Would you help me to carry the stone?" Pink Floyd

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message