You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Musachy Barroso <mu...@gmail.com> on 2008/07/21 19:35:47 UTC
[PROPOSAL] Deprecate or remove Dojo plugin
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.
We haven't released 2.1 yet, so this would be a perfect time to do
this, as it is already on its own plugin.
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Miguel <mi...@gmail.com>.
I have some code using jquery that submits a form using jquery and
fits the returned result in a target div, and a A tag that does the
same. Both codes don't have topics or any other sofistication. In
fact, using jquery is a breeze (and i feel dojo an *extremely*
complicated thing). Making the jquery code a freemaker template
doesn't seem complicated, although I've never messed with freemaker.
One thing i should ask, is: is there any way to "centralize" some code
generated via a template? let explain myself, if I put various <s:a
...> tags, each one would need a <script> /*init code, very little
code*/ <script> attached, to initialize the behaviour, how do I
"centralize" the js in one bigger <script> block at the begining or
the end of the generated page?
Thanks
Si quieres ser más positivo, pierde un electrón
Miguel Ruiz Velasco S.
On Mon, Jul 21, 2008 at 12:44, James Holmes <ja...@jamesholmes.com> wrote:
> +1.
>
> I'd rather us not lose the AJAX tags, but rather implement with something
> more lightweight like Prototype, jQuery, or similar that's much easier to
> work with.
>
> On Mon, Jul 21, 2008 at 1:35 PM, Musachy Barroso <mu...@gmail.com> 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.
>>
>> We haven't released 2.1 yet, so this would be a perfect time to do
>> this, as it is already on its own plugin.
>>
>> musachy
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> 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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by James Holmes <ja...@jamesholmes.com>.
+1.
I'd rather us not lose the AJAX tags, but rather implement with something
more lightweight like Prototype, jQuery, or similar that's much easier to
work with.
On Mon, Jul 21, 2008 at 1:35 PM, Musachy Barroso <mu...@gmail.com> 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.
>
> We haven't released 2.1 yet, so this would be a perfect time to do
> this, as it is already on its own plugin.
>
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
RE: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by "Karr, David" <da...@wamu.net>.
> -----Original Message-----
> From: Musachy Barroso [mailto:musachy@gmail.com]
> Sent: Monday, July 21, 2008 10:36 AM
> To: Struts Developers List
> Subject: [PROPOSAL] Deprecate or remove Dojo plugin
>
> 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.
I would certainly agree with this, but I think it's important to
emphasize that the solution is NOT to find a different framework or
version to integrate into Struts. The best solution is to visualize how
to facilitate integrating any capable JavaScript framework into a
Struts-using application. That does not mean embedding a JavaScript
framework into the Struts distribution. To a large extent, the biggest
part of this solution is documentation, but it's possible that some
other changes to the framework could make this easier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Piero Sartini <li...@pierosartini.de>.
> What does anyone think about donating the dojo plugin to codehaus? I think
> it's a better idea than letting the code go stale. You could even try
> donating to the dojotoolkit project.
I am not sure what you mean by donating it to codehaus. If someone wants to
support the plugin he may do so under the terms of the APLv2. The actual
problem is that there is nobody who thinks that it is worth the work.
Wether the code "stales" at codehaus or apache.. what is the difference?
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-dev] [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Dale Newfield <Da...@Newfield.org>.
Frank W. Zammetti wrote:
> Think about all you're taking for granted when you write
> $("#content).load(url);
It largely boils down to differences between how developers think the
dom/language works and how it really works.
The time it takes to have your developers watch Crockford's three
lectures is *well* worth it.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I think that ignores the underlying complexity of developing complex
RIAs today. I would take any of the apps I've developed on the job over
the past 5+ years and put them up against any out there in terms of
complexity... when I talk to other developers about what they're doing
it's nearly always the case that what they describe is orders of
magnitude less complex than some of the project I've been involved in.
And all the while I've had to mentor teams to get them up to speed so
they could develop these applications with me. I'm not saying any of
that to try and be impressive, I'm saying that so I can then say this:
the paradigm shift of doing heavy client-side AJAX-based RIA development
when you are used to doing the "classic" server-heavy model of web
development isn't as simple as choosing a good library and doing some
simple calls as you show. Things just aren't that simple once you move
beyond "level 1", so to speak :)
Now, I suppose you could say that then a taglib approach is quickly
going to become not up to the task either, which I'd agree with. You
could further say that if that's the case, why not just start by
learning a good library and forget about tags. There's some degree of
correctness in that I think. But I've seen it time and time again: good
Java developers who transition to a client-side model just seem to have
trouble "getting it", and whether you use tags or a library directly it
doesn't seem to matter. Things that I, and I suspect you, would take
for granted seem difficult for them to comprehend... things like
following the applications' flow when things are moving from server to
client, timing issues, dealing with security, not to mention the still
less-than-optimal debugging capabilities available.
But what I've *also* seen time and time again is that a tag-based
approached is easier for them to wrap their brains around initially than
using a library directly because it's closer to what they already know.
Think about all you're taking for granted when you write
$("#content).load(url); ... you assume they know about the DOM, that
they understand the concept of a URL's response not overwriting the
entire page... and what does that call look like when you have to deal
with error callbacks? And timeout conditions? And security
constraints? Is it still as simple as just that? If so then jQuery is
more than good, it's freakin' miraclulous!
Having a taglib, at least initially, that keeps those details away from
them is a good thing... yes, they'll quickly outgrow them, but then
they'll quickly come to the point you're at and want to use the
libraries directly, and will at that point no longer be the huge mental
leap that it was at the start.
Frank
--
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
Bob Tiernay wrote:
>
>> 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.
>
> Today's whiz-bang libraries make things dead simple to perform ajax
> requests. For instance, with jQuery to get the contents of a url and
> place it in a div element #content:
>
> $("#content).load(url);
>
> I guess I fail to see how even junior-level team members would have a
> difficult learning curve with this. Learning jQuery quickly is easy
> to do and is much of the appeal.
>
> And as others have mentioned, the libraries such as jQuery have a
> great user base, with much to offer in terms of support. Just
> checkout the #jquery freenode irc channel, for instance.
>
> Part of being a developer is learning new technologies, and if those
> technologies are easy to use and powerful, then that's where the ROI
> really pays off. We should be nudging people in these directions with
> better documentation on how to best integrate with existing libraries.
> This would be a far better place to focus energy, imo.
>
> Bob
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Bob Tiernay <bt...@hotmail.com>.
> 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.
Today's whiz-bang libraries make things dead simple to perform ajax
requests. For instance, with jQuery to get the contents of a url and place
it in a div element #content:
$("#content).load(url);
I guess I fail to see how even junior-level team members would have a
difficult learning curve with this. Learning jQuery quickly is easy to do
and is much of the appeal.
And as others have mentioned, the libraries such as jQuery have a great user
base, with much to offer in terms of support. Just checkout the #jquery
freenode irc channel, for instance.
Part of being a developer is learning new technologies, and if those
technologies are easy to use and powerful, then that's where the ROI really
pays off. We should be nudging people in these directions with better
documentation on how to best integrate with existing libraries. This would
be a far better place to focus energy, imo.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Paul Benedict <pb...@apache.org>.
If this is the case, I would not recommend we create an "ajax" plugin, but
call it the "ajax-yui" plugin or a "ajax-whatever" plugin so that people can
use different ajax implementations.
Paul
On Wed, Jul 23, 2008 at 1:40 AM, Jeromy Evans <
jeromy.evans@blueskyminds.com.au> wrote:
> Paul Benedict wrote:
>
>> 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
>>
>>
>
> Many have tried. In general, the effort doesn't justify the result.
> ie. you put a lot of effort writing new templates and tags that
> predominately wrap and constrain dojo's own markup. This result is tags for
> widgets less capable than using dojo markup directly. The benefit is a user
> can use <s:tabbedPanel> instead of <div dojoType="TabContainer">, but if
> they use the latter they can receive all the support of the dojo user
> community.
>
> It's difficult to justify the effort for a sub-optimal solution that's
> going to generate more support questions:
> eg. how to I select a tab a button press, how to i change colour of tabs,
> why can't i nest tabs, why won't the back button remember the content of the
> last tab, etc, etc, etc,
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Paul Benedict wrote:
> 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
>
Many have tried. In general, the effort doesn't justify the result.
ie. you put a lot of effort writing new templates and tags that
predominately wrap and constrain dojo's own markup. This result is tags
for widgets less capable than using dojo markup directly. The benefit
is a user can use <s:tabbedPanel> instead of <div
dojoType="TabContainer">, but if they use the latter they can receive
all the support of the dojo user community.
It's difficult to justify the effort for a sub-optimal solution that's
going to generate more support questions:
eg. how to I select a tab a button press, how to i change colour of
tabs, why can't i nest tabs, why won't the back button remember the
content of the last tab, etc, etc, etc,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Paul Benedict <pb...@apache.org>.
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 <fz...@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 <mu...@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
>
>
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <mu...@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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Musachy Barroso <mu...@gmail.com>.
That would be totally fine, but I doubt anyone would be interested in
Dojo 0.4.3 at this point.
musachy
On Tue, Jul 22, 2008 at 7:29 PM, Paul Benedict <pb...@apache.org> wrote:
> What does anyone think about donating the dojo plugin to codehaus? I think
> it's a better idea than letting the code go stale. You could even try
> donating to the dojotoolkit project.
>
> Paul
>
> On Tue, Jul 22, 2008 at 6:18 PM, Ted Husted <hu...@apache.org> 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 <mu...@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
>>
>>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Paul Benedict <pb...@apache.org>.
What does anyone think about donating the dojo plugin to codehaus? I think
it's a better idea than letting the code go stale. You could even try
donating to the dojotoolkit project.
Paul
On Tue, Jul 22, 2008 at 6:18 PM, Ted Husted <hu...@apache.org> 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 <mu...@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
>
>
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Musachy Barroso <mu...@gmail.com>.
> Has anyone had good or bad experiences with tag-based libraries like these?
>
I used to maintain Ajax Tags, but I thought there were too many
frameworks already and gave it away :). I haven't used any of the
other ones.
musachy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Ted Husted <hu...@apache.org>.
+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 <mu...@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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Lukasz Lenart <lu...@googlemail.com>.
> You would have to start the tags from scratch.
Very optimistic ;-) Maybe than, the jQuery is a better option to start
from scratch..
Regards
--
Lukasz
http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Musachy Barroso <mu...@gmail.com>.
You would have to start the tags from scratch.
musachy
On Tue, Jul 22, 2008 at 1:56 AM, Lukasz Lenart
<lu...@googlemail.com> wrote:
> Hi,
>
>> 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.
>
> I'm just wondering, what have to be done to migrate to the latest
> version of Dojo toolkit? I'm not using S2 Ajax tags at all (for me DWR
> is enough ;-) and maybe that's the good point to start learnig them
> and also support future development?
>
>
> Regards
> --
> Lukasz
> http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Lukasz Lenart <lu...@googlemail.com>.
Hi,
> 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.
I'm just wondering, what have to be done to migrate to the latest
version of Dojo toolkit? I'm not using S2 Ajax tags at all (for me DWR
is enough ;-) and maybe that's the good point to start learnig them
and also support future development?
Regards
--
Lukasz
http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Musachy Barroso <mu...@gmail.com>.
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
On Mon, Jul 21, 2008 at 10:24 PM, Jeromy Evans
<je...@blueskyminds.com.au> 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).
>
> NOTE:
> Ajax validation and client-side validation also deserve some discussion
> later.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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).
NOTE:
Ajax validation and client-side validation also deserve some discussion
later.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Gabriel Belingueres <be...@gmail.com>.
Tapestry is using Dojo too [1].
I'm not developing any AJAX application so my comments could be
somewhat biased, but either the dojo toolkit is used or not in
upcoming S2 versions, I think it is still worthwhile providing easy to
use, good looking javascript/dhtml widgets to quickly solve form input
problems for most applications. Input validation could become improved
with more sophisticated widgets too.
Also, the default packaging/integration of Dojo with S2 was known to
have serious performance problems, lets not lose focus on this issue
too.
[1] http://tapestry.apache.org/tapestry4.1/
2008/7/22 Dave Newton <ne...@yahoo.com>:
> --- On Tue, 7/22/08, Paul Benedict <pb...@apache.org> wrote:
>> Isn't Dojo the defacto ajax standard on the web?
>
> In terms of deployments I'd put money on Prototype and/or jQuery. Not that it's a large sample size, but I don't know *anybody* using Dojo outside of S2.
>
> Dave
>
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Al Sutton <al...@alsutton.com>.
ExtJS is a big no-no in my book. To use it in a commercial project you
need to buy a license, which would put off a lot of commercial customers.
Personally I use YUI for two reasons;
1) It's easy to separate out and include only the parts I need in my
webapp so I don't end up with war bloat.
2) The mailing lists seemed reasonably active.
Al.
Martin Cooper wrote:
> On Tue, Jul 22, 2008 at 3:57 PM, Ted Husted <hu...@apache.org> wrote:
>
>
>> Dojo seems to get the most lip service, but I've seen persistence
>> reports that YUI has broader acceptance.
>>
>
>
> The thing is, it depends a whole lot on what you are doing with it.
>
> For example, the people I know who are developing rich client-side apps with
> JavaScript are using Ext JS or Dojo. None of them are using YUI because YUI
> simply isn't appropriate, or complete enough, for that kind of usage. It's
> perfectly fine, though, if what you want is to add some AJAXy capabilities
> to a more traditional web app.
>
> As another example, there are certainly plenty of people building point
> applications with Prototype and its friends, but if you're building
> something that needs to be extensible and include components from elsewhere,
> you almost certainly don't want to be using a framework that messes with
> core JavaScript types.
>
> --
> Martin Cooper
>
>
>
>> -Ted.
>>
>> On Tue, Jul 22, 2008 at 4:48 PM, Dave Newton <ne...@yahoo.com>
>> wrote:
>>
>>> --- On Tue, 7/22/08, Paul Benedict <pb...@apache.org> wrote:
>>>
>>>> Isn't Dojo the defacto ajax standard on the web?
>>>>
>>> In terms of deployments I'd put money on Prototype and/or jQuery. Not
>>>
>> that it's a large sample size, but I don't know *anybody* using Dojo outside
>> of S2.
>>
>>> Dave
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>> --
>> HTH, Ted
>> http://husted.com/ted/blog/
>>
>> ---------------------------------------------------------------------
>> 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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Ted Husted <hu...@apache.org>.
On Tue, Jul 22, 2008 at 8:19 PM, Dave Newton <ne...@yahoo.com> wrote:
> --- On Tue, 7/22/08, Bob Tiernay <bt...@hotmail.com> wrote:
>> I really don't see why even a taglib is even on the table.
>
> I think the issue was a "let's make some of this cool stuff really easy for the people that don't know JavaScript."
True. There are a lot of applications that don't need or want a full
client-side front-end. For a lot of folks, full-page refresh is just
fine most of the time, but there is still a key place or three where
sprinkling in a little Ajax magic can make a big difference, without
making any sweeping UI changes. We don't need to hookup an entire
general -purpose Ajax framework for that. We just need to go in with a
scalpel and add some simple Ajax scripts where they will do the most
good.
Of course, if an application has already elected to use a full
clientde front-end, anything we do with the tags would be irrelevant.
-Ted.
>
> To steal the phrase: now you have two problems.
>
> I'm not sure it's worth keeping the Dojo tags as part of S2, particularly since client-side "stuff" varies so wildly across companies (even *within* companies), developers, projects, etc.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted
http://husted.com/ted/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Martin Cooper <ma...@apache.org>.
On Tue, Jul 22, 2008 at 4:44 PM, Bob Tiernay <bt...@hotmail.com> wrote:
> Has anyone really looked into a comparison between using a taglib vs. a raw
> javascript framework across these dimensions:
Hey, don't look at me - I gave up using server-side rendering years ago! ;-)
--
Martin Cooper
> 1. Performance (page load time / bandwidth) (think s:head across most
> pages)
> 2. Expressiveness
> 3. Unobtrusiveness
> 4. Maintainability
> 5. Understandability
> 6. Modularity
>
> My experience has been that all of these are enhanced when using the later.
> I really don't see why even a taglib is even on the table. Perhaps I'm
> missing something here, but what is to be gained by unifying javascript
> libraries with a taglib façade? This smells of commons logging.
>
> --------------------------------------------------
> From: "Martin Cooper" <ma...@apache.org>
> Sent: Tuesday, July 22, 2008 7:36 PM
> To: "Struts Developers List" <de...@struts.apache.org>
> Cc: <ne...@yahoo.com>
> Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin
>
>
> On Tue, Jul 22, 2008 at 3:57 PM, Ted Husted <hu...@apache.org> wrote:
>>
>> Dojo seems to get the most lip service, but I've seen persistence
>>> reports that YUI has broader acceptance.
>>>
>>
>>
>> The thing is, it depends a whole lot on what you are doing with it.
>>
>> For example, the people I know who are developing rich client-side apps
>> with
>> JavaScript are using Ext JS or Dojo. None of them are using YUI because
>> YUI
>> simply isn't appropriate, or complete enough, for that kind of usage. It's
>> perfectly fine, though, if what you want is to add some AJAXy capabilities
>> to a more traditional web app.
>>
>> As another example, there are certainly plenty of people building point
>> applications with Prototype and its friends, but if you're building
>> something that needs to be extensible and include components from
>> elsewhere,
>> you almost certainly don't want to be using a framework that messes with
>> core JavaScript types.
>>
>> --
>> Martin Cooper
>>
>>
>>
>>> -Ted.
>>>
>>> On Tue, Jul 22, 2008 at 4:48 PM, Dave Newton <ne...@yahoo.com>
>>> wrote:
>>> > --- On Tue, 7/22/08, Paul Benedict <pb...@apache.org> wrote:
>>> >> Isn't Dojo the defacto ajax standard on the web?
>>> >
>>> > In terms of deployments I'd put money on Prototype and/or jQuery. Not
>>> that it's a large sample size, but I don't know *anybody* using Dojo
>>> outside
>>> of S2.
>>> >
>>> > Dave
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> > For additional commands, e-mail: dev-help@struts.apache.org
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> HTH, Ted
>>> http://husted.com/ted/blog/
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Dave Newton <ne...@yahoo.com>.
--- On Tue, 7/22/08, Bob Tiernay <bt...@hotmail.com> wrote:
> I really don't see why even a taglib is even on the table.
I think the issue was a "let's make some of this cool stuff really easy for the people that don't know JavaScript."
To steal the phrase: now you have two problems.
I'm not sure it's worth keeping the Dojo tags as part of S2, particularly since client-side "stuff" varies so wildly across companies (even *within* companies), developers, projects, etc.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Bob Tiernay <bt...@hotmail.com>.
Has anyone really looked into a comparison between using a taglib vs. a raw
javascript framework across these dimensions:
1. Performance (page load time / bandwidth) (think s:head across most pages)
2. Expressiveness
3. Unobtrusiveness
4. Maintainability
5. Understandability
6. Modularity
My experience has been that all of these are enhanced when using the later.
I really don't see why even a taglib is even on the table. Perhaps I'm
missing something here, but what is to be gained by unifying javascript
libraries with a taglib façade? This smells of commons logging.
--------------------------------------------------
From: "Martin Cooper" <ma...@apache.org>
Sent: Tuesday, July 22, 2008 7:36 PM
To: "Struts Developers List" <de...@struts.apache.org>
Cc: <ne...@yahoo.com>
Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin
> On Tue, Jul 22, 2008 at 3:57 PM, Ted Husted <hu...@apache.org> wrote:
>
>> Dojo seems to get the most lip service, but I've seen persistence
>> reports that YUI has broader acceptance.
>
>
> The thing is, it depends a whole lot on what you are doing with it.
>
> For example, the people I know who are developing rich client-side apps
> with
> JavaScript are using Ext JS or Dojo. None of them are using YUI because
> YUI
> simply isn't appropriate, or complete enough, for that kind of usage. It's
> perfectly fine, though, if what you want is to add some AJAXy capabilities
> to a more traditional web app.
>
> As another example, there are certainly plenty of people building point
> applications with Prototype and its friends, but if you're building
> something that needs to be extensible and include components from
> elsewhere,
> you almost certainly don't want to be using a framework that messes with
> core JavaScript types.
>
> --
> Martin Cooper
>
>
>>
>> -Ted.
>>
>> On Tue, Jul 22, 2008 at 4:48 PM, Dave Newton <ne...@yahoo.com>
>> wrote:
>> > --- On Tue, 7/22/08, Paul Benedict <pb...@apache.org> wrote:
>> >> Isn't Dojo the defacto ajax standard on the web?
>> >
>> > In terms of deployments I'd put money on Prototype and/or jQuery. Not
>> that it's a large sample size, but I don't know *anybody* using Dojo
>> outside
>> of S2.
>> >
>> > Dave
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>>
>> --
>> HTH, Ted
>> http://husted.com/ted/blog/
>>
>> ---------------------------------------------------------------------
>> 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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Martin Cooper <ma...@apache.org>.
On Tue, Jul 22, 2008 at 3:57 PM, Ted Husted <hu...@apache.org> wrote:
> Dojo seems to get the most lip service, but I've seen persistence
> reports that YUI has broader acceptance.
The thing is, it depends a whole lot on what you are doing with it.
For example, the people I know who are developing rich client-side apps with
JavaScript are using Ext JS or Dojo. None of them are using YUI because YUI
simply isn't appropriate, or complete enough, for that kind of usage. It's
perfectly fine, though, if what you want is to add some AJAXy capabilities
to a more traditional web app.
As another example, there are certainly plenty of people building point
applications with Prototype and its friends, but if you're building
something that needs to be extensible and include components from elsewhere,
you almost certainly don't want to be using a framework that messes with
core JavaScript types.
--
Martin Cooper
>
> -Ted.
>
> On Tue, Jul 22, 2008 at 4:48 PM, Dave Newton <ne...@yahoo.com>
> wrote:
> > --- On Tue, 7/22/08, Paul Benedict <pb...@apache.org> wrote:
> >> Isn't Dojo the defacto ajax standard on the web?
> >
> > In terms of deployments I'd put money on Prototype and/or jQuery. Not
> that it's a large sample size, but I don't know *anybody* using Dojo outside
> of S2.
> >
> > Dave
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> HTH, Ted
> http://husted.com/ted/blog/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Ted Husted <hu...@apache.org>.
Dojo seems to get the most lip service, but I've seen persistence
reports that YUI has broader acceptance.
-Ted.
On Tue, Jul 22, 2008 at 4:48 PM, Dave Newton <ne...@yahoo.com> wrote:
> --- On Tue, 7/22/08, Paul Benedict <pb...@apache.org> wrote:
>> Isn't Dojo the defacto ajax standard on the web?
>
> In terms of deployments I'd put money on Prototype and/or jQuery. Not that it's a large sample size, but I don't know *anybody* using Dojo outside of S2.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted
http://husted.com/ted/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Rene Gielen <gi...@it-neering.net>.
It's interesting to see the list of dojo sponsors and supporters
(http://dojotoolkit.org/foundation) on the one side, and the slow and
always API breaking development on the other. If they had a 1.0 out a
year ago, along with a stable API, it might have had a chance to become
something like a standard, but this is actually not the case.
Another interesting point to me is that dojo seems to focus more and
more on building fully dynamic UIs with Javascript, but compared to do
the same with ExtJS, GWT-Ext or GWT, using Dojo is a real pain.
Dave Newton schrieb:
> --- On Tue, 7/22/08, Paul Benedict <pb...@apache.org> wrote:
>> Isn't Dojo the defacto ajax standard on the web?
>
> In terms of deployments I'd put money on Prototype and/or jQuery. Not that it's a large sample size, but I don't know *anybody* using Dojo outside of S2.
>
> Dave
>
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Dave Newton <ne...@yahoo.com>.
--- On Tue, 7/22/08, Paul Benedict <pb...@apache.org> wrote:
> Isn't Dojo the defacto ajax standard on the web?
In terms of deployments I'd put money on Prototype and/or jQuery. Not that it's a large sample size, but I don't know *anybody* using Dojo outside of S2.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Paul Benedict <pb...@apache.org>.
Isn't Dojo the defacto ajax standard on the web? I know there is no such
"certification" :-) but why deprecate something so popular? If anything, I
would spin off the project into Codehaus and let the world continue writing
it.
Paul
On Tue, Jul 22, 2008 at 10:18 AM, Dave Newton <ne...@yahoo.com> wrote:
> --- On Tue, 7/22/08, Musachy Barroso <mu...@gmail.com> wrote:
> > I think Dave also had a JQuery plugin somewhere, isn't that right?
>
> I can neither confirm nor deny the existence of said project.
>
> I started to convert the Dojo tags to jQuery and stopped again pretty
> quickly; I only had <s:a.../> with a single target.
>
> I started w/ the Dojo tag code, as I had wanted to make them as compatible
> as practical w/ the Dojo tags. My project then did everything via raw jQuery
> anyway, so they got put on hold.
>
> To answer somebody else's question, I gathered JavaScript in a couple of
> different ways across projects, including keeping it in a ThreadLocal String
> then spitting it out with a tag or appending it via an interceptor (not sure
> that was HTML-compliant though).
>
> I agree that having things like <s:a...> and an Ajax submit would be pretty
> nice--make the easy stuff drop-dead simple. Anything beyond that I'm less
> sure, and tying S2 itself to a particular client-side framework always
> worried me a bit.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Musachy Barroso <mu...@gmail.com>.
yeah, that's what I had in mind.
musachy
On Thu, Jul 24, 2008 at 3:48 PM, Ted Husted <hu...@apache.org> wrote:
> I'd suggest that we put a replacement together before pulling the Dojo
> plugin out of the distribution (I can help). We could at least
> deprecate Dojo in the meantime.
>
> -T.
>
> On Thu, Jul 24, 2008 at 3:44 PM, Musachy Barroso <mu...@gmail.com> wrote:
>> So is the consensus so far that we should have a few, very simple
>> tags, based on another framework, and take the dojo plugin out of
>> struts?
>>
>> musachy
>>
>> On Thu, Jul 24, 2008 at 7:20 AM, Dave Newton <ne...@yahoo.com> wrote:
>>> One solution would be to provide the backing components for simple use-cases (like <sx:a...> and <sx:submit...> at least) and an integration with a couple JavaScript libraries, hopefully making it obvious enough that people could then implement their own back-end.
>>>
>>> With simple components updating on backing library updates is easier, and (in theory) it makes it easier to understand how users can extend or create additional tags to suit their needs.
>>>
>>> So I vote +1 for removing the existing Dojo plugin (+0 for deprecating) and +1 for creating the simplistic components and example integrations.
>>>
>>> Dave
>>>
>>> --- On Tue, 7/22/08, Musachy Barroso <mu...@gmail.com> wrote:
>>>
>>>> From: Musachy Barroso <mu...@gmail.com>
>>>> Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin
>>>> To: "Struts Developers List" <de...@struts.apache.org>
>>>> Date: Tuesday, July 22, 2008, 9:34 AM
>>>> I think Dave also had a JQuery plugin somewhere, isn't
>>>> that right?
>>>>
>>>> musachy
>>>>
>>>> On Tue, Jul 22, 2008 at 7:49 AM, alvins
>>>> <al...@hotmail.com> wrote:
>>>> >
>>>> > +1 to remove.
>>>> >
>>>> > Valid points raised by all. I personally use JQuery in
>>>> my daily life and
>>>> > have written my own tags to do these functions. I did
>>>> previously look at the
>>>> > effort required to update the current tags to the
>>>> latest dojo but it would
>>>> > be very time consuming and far easier to start from
>>>> scratch. I think a
>>>> > large problem with the current dojo tags are that it
>>>> is very complicated to
>>>> > do simple things (dojo itself is complicated
>>>> relatively).
>>>> >
>>>> > With JQuery it is quite easy to do most of the things
>>>> mentioned so am not
>>>> > sure on the benefits of tags. That said - if you made
>>>> the tags powerful
>>>> > enough - they can be quite useful in a large number of
>>>> cases - however the
>>>> > flipside is as you add functionality, maintainability
>>>> becomes an issue.
>>>> >
>>>> > btw. If anybody is interested in some JQuery tags I
>>>> could start a plugin..?
>>>> > --
>>>> > View this message in context:
>>>> http://www.nabble.com/-PROPOSAL--Deprecate-or-remove-Dojo-plugin-tp18573704p18587222.html
>>>> > Sent from the Struts - Dev mailing list archive at
>>>> Nabble.com.
>>>> >
>>>> >
>>>> >
>>>> ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail:
>>>> dev-unsubscribe@struts.apache.org
>>>> > For additional commands, e-mail:
>>>> dev-help@struts.apache.org
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> "Hey you! Would you help me to carry the stone?"
>>>> Pink Floyd
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> HTH, Ted
> http://husted.com/ted/blog/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Dave Newton <ne...@yahoo.com>.
I was thinking about all this last night.
One thing that might be useful is to provide enough information to implement existing tags in raw Dojo/JavaScript--there's enough being done by the S2 components/tags that it might throw a lot of people off to write it by hand.
Sort of a migration guide.
Dave
--- On Thu, 7/24/08, Ted Husted <hu...@apache.org> wrote:
> From: Ted Husted <hu...@apache.org>
> Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin
> To: "Struts Developers List" <de...@struts.apache.org>
> Date: Thursday, July 24, 2008, 3:48 PM
> I'd suggest that we put a replacement together before
> pulling the Dojo
> plugin out of the distribution (I can help). We could at
> least
> deprecate Dojo in the meantime.
>
> -T.
>
> On Thu, Jul 24, 2008 at 3:44 PM, Musachy Barroso
> <mu...@gmail.com> wrote:
> > So is the consensus so far that we should have a few,
> very simple
> > tags, based on another framework, and take the dojo
> plugin out of
> > struts?
> >
> > musachy
> >
> > On Thu, Jul 24, 2008 at 7:20 AM, Dave Newton
> <ne...@yahoo.com> wrote:
> >> One solution would be to provide the backing
> components for simple use-cases (like <sx:a...> and
> <sx:submit...> at least) and an integration with a
> couple JavaScript libraries, hopefully making it obvious
> enough that people could then implement their own back-end.
> >>
> >> With simple components updating on backing library
> updates is easier, and (in theory) it makes it easier to
> understand how users can extend or create additional tags
> to suit their needs.
> >>
> >> So I vote +1 for removing the existing Dojo plugin
> (+0 for deprecating) and +1 for creating the simplistic
> components and example integrations.
> >>
> >> Dave
> >>
> >> --- On Tue, 7/22/08, Musachy Barroso
> <mu...@gmail.com> wrote:
> >>
> >>> From: Musachy Barroso
> <mu...@gmail.com>
> >>> Subject: Re: [PROPOSAL] Deprecate or remove
> Dojo plugin
> >>> To: "Struts Developers List"
> <de...@struts.apache.org>
> >>> Date: Tuesday, July 22, 2008, 9:34 AM
> >>> I think Dave also had a JQuery plugin
> somewhere, isn't
> >>> that right?
> >>>
> >>> musachy
> >>>
> >>> On Tue, Jul 22, 2008 at 7:49 AM, alvins
> >>> <al...@hotmail.com> wrote:
> >>> >
> >>> > +1 to remove.
> >>> >
> >>> > Valid points raised by all. I personally
> use JQuery in
> >>> my daily life and
> >>> > have written my own tags to do these
> functions. I did
> >>> previously look at the
> >>> > effort required to update the current
> tags to the
> >>> latest dojo but it would
> >>> > be very time consuming and far easier to
> start from
> >>> scratch. I think a
> >>> > large problem with the current dojo tags
> are that it
> >>> is very complicated to
> >>> > do simple things (dojo itself is
> complicated
> >>> relatively).
> >>> >
> >>> > With JQuery it is quite easy to do most
> of the things
> >>> mentioned so am not
> >>> > sure on the benefits of tags. That said -
> if you made
> >>> the tags powerful
> >>> > enough - they can be quite useful in a
> large number of
> >>> cases - however the
> >>> > flipside is as you add functionality,
> maintainability
> >>> becomes an issue.
> >>> >
> >>> > btw. If anybody is interested in some
> JQuery tags I
> >>> could start a plugin..?
> >>> > --
> >>> > View this message in context:
> >>>
> http://www.nabble.com/-PROPOSAL--Deprecate-or-remove-Dojo-plugin-tp18573704p18587222.html
> >>> > Sent from the Struts - Dev mailing list
> archive at
> >>> Nabble.com.
> >>> >
> >>> >
> >>> >
> >>>
> ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail:
> >>> dev-unsubscribe@struts.apache.org
> >>> > For additional commands, e-mail:
> >>> dev-help@struts.apache.org
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> "Hey you! Would you help me to carry the
> stone?"
> >>> Pink Floyd
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> >
> > --
> > "Hey you! Would you help me to carry the
> stone?" Pink Floyd
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail:
> dev-help@struts.apache.org
> >
> >
>
>
>
> --
> HTH, Ted
> http://husted.com/ted/blog/
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Ted Husted <hu...@apache.org>.
Yes, I just want to get a handle on GXP first, to see if there's any
synergy between the two proposals. (Trying to get the tests to run
now.)
On Sun, Jul 27, 2008 at 11:55 AM, Musachy Barroso <mu...@gmail.com> wrote:
> My hand are full for the next couple of weeks (releases at work), but
> I can jump in and help from time to time. Ted, do you want get started
> on them? I would suggest we setup a project in the sandbox.
>
> musachy
>
> On Thu, Jul 24, 2008 at 5:40 PM, Jeromy Evans
> <je...@blueskyminds.com.au> wrote:
>> Ted Husted wrote:
>>>
>>> I'd suggest that we put a replacement together before pulling the Dojo
>>> plugin out of the distribution (I can help). We could at least
>>> deprecate Dojo in the meantime.
>>>
>>> -T.
>>>
>>
>> I can help too but I'm moving house today so may be offline for a while (it
>> takes weeks to get a new adsl2 connection in this country).
>>
>> I committed some minimal remote div, anchor, submit and tabbed panel tags to
>> the yuiplugin a while ago. I'd rewrite all the javascript again to not mess
>> with the namespace if I were using them but they may prompt some ideas.
>> http://code.google.com/p/struts2yuiplugin/downloads/list
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Musachy Barroso <mu...@gmail.com>.
My hand are full for the next couple of weeks (releases at work), but
I can jump in and help from time to time. Ted, do you want get started
on them? I would suggest we setup a project in the sandbox.
musachy
On Thu, Jul 24, 2008 at 5:40 PM, Jeromy Evans
<je...@blueskyminds.com.au> wrote:
> Ted Husted wrote:
>>
>> I'd suggest that we put a replacement together before pulling the Dojo
>> plugin out of the distribution (I can help). We could at least
>> deprecate Dojo in the meantime.
>>
>> -T.
>>
>
> I can help too but I'm moving house today so may be offline for a while (it
> takes weeks to get a new adsl2 connection in this country).
>
> I committed some minimal remote div, anchor, submit and tabbed panel tags to
> the yuiplugin a while ago. I'd rewrite all the javascript again to not mess
> with the namespace if I were using them but they may prompt some ideas.
> http://code.google.com/p/struts2yuiplugin/downloads/list
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Ted Husted wrote:
> I'd suggest that we put a replacement together before pulling the Dojo
> plugin out of the distribution (I can help). We could at least
> deprecate Dojo in the meantime.
>
> -T.
>
I can help too but I'm moving house today so may be offline for a while
(it takes weeks to get a new adsl2 connection in this country).
I committed some minimal remote div, anchor, submit and tabbed panel
tags to the yuiplugin a while ago. I'd rewrite all the javascript again
to not mess with the namespace if I were using them but they may prompt
some ideas.
http://code.google.com/p/struts2yuiplugin/downloads/list
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Ted Husted <hu...@apache.org>.
I'd suggest that we put a replacement together before pulling the Dojo
plugin out of the distribution (I can help). We could at least
deprecate Dojo in the meantime.
-T.
On Thu, Jul 24, 2008 at 3:44 PM, Musachy Barroso <mu...@gmail.com> wrote:
> So is the consensus so far that we should have a few, very simple
> tags, based on another framework, and take the dojo plugin out of
> struts?
>
> musachy
>
> On Thu, Jul 24, 2008 at 7:20 AM, Dave Newton <ne...@yahoo.com> wrote:
>> One solution would be to provide the backing components for simple use-cases (like <sx:a...> and <sx:submit...> at least) and an integration with a couple JavaScript libraries, hopefully making it obvious enough that people could then implement their own back-end.
>>
>> With simple components updating on backing library updates is easier, and (in theory) it makes it easier to understand how users can extend or create additional tags to suit their needs.
>>
>> So I vote +1 for removing the existing Dojo plugin (+0 for deprecating) and +1 for creating the simplistic components and example integrations.
>>
>> Dave
>>
>> --- On Tue, 7/22/08, Musachy Barroso <mu...@gmail.com> wrote:
>>
>>> From: Musachy Barroso <mu...@gmail.com>
>>> Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin
>>> To: "Struts Developers List" <de...@struts.apache.org>
>>> Date: Tuesday, July 22, 2008, 9:34 AM
>>> I think Dave also had a JQuery plugin somewhere, isn't
>>> that right?
>>>
>>> musachy
>>>
>>> On Tue, Jul 22, 2008 at 7:49 AM, alvins
>>> <al...@hotmail.com> wrote:
>>> >
>>> > +1 to remove.
>>> >
>>> > Valid points raised by all. I personally use JQuery in
>>> my daily life and
>>> > have written my own tags to do these functions. I did
>>> previously look at the
>>> > effort required to update the current tags to the
>>> latest dojo but it would
>>> > be very time consuming and far easier to start from
>>> scratch. I think a
>>> > large problem with the current dojo tags are that it
>>> is very complicated to
>>> > do simple things (dojo itself is complicated
>>> relatively).
>>> >
>>> > With JQuery it is quite easy to do most of the things
>>> mentioned so am not
>>> > sure on the benefits of tags. That said - if you made
>>> the tags powerful
>>> > enough - they can be quite useful in a large number of
>>> cases - however the
>>> > flipside is as you add functionality, maintainability
>>> becomes an issue.
>>> >
>>> > btw. If anybody is interested in some JQuery tags I
>>> could start a plugin..?
>>> > --
>>> > View this message in context:
>>> http://www.nabble.com/-PROPOSAL--Deprecate-or-remove-Dojo-plugin-tp18573704p18587222.html
>>> > Sent from the Struts - Dev mailing list archive at
>>> Nabble.com.
>>> >
>>> >
>>> >
>>> ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail:
>>> dev-unsubscribe@struts.apache.org
>>> > For additional commands, e-mail:
>>> dev-help@struts.apache.org
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?"
>>> Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted
http://husted.com/ted/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Musachy Barroso <mu...@gmail.com>.
So is the consensus so far that we should have a few, very simple
tags, based on another framework, and take the dojo plugin out of
struts?
musachy
On Thu, Jul 24, 2008 at 7:20 AM, Dave Newton <ne...@yahoo.com> wrote:
> One solution would be to provide the backing components for simple use-cases (like <sx:a...> and <sx:submit...> at least) and an integration with a couple JavaScript libraries, hopefully making it obvious enough that people could then implement their own back-end.
>
> With simple components updating on backing library updates is easier, and (in theory) it makes it easier to understand how users can extend or create additional tags to suit their needs.
>
> So I vote +1 for removing the existing Dojo plugin (+0 for deprecating) and +1 for creating the simplistic components and example integrations.
>
> Dave
>
> --- On Tue, 7/22/08, Musachy Barroso <mu...@gmail.com> wrote:
>
>> From: Musachy Barroso <mu...@gmail.com>
>> Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin
>> To: "Struts Developers List" <de...@struts.apache.org>
>> Date: Tuesday, July 22, 2008, 9:34 AM
>> I think Dave also had a JQuery plugin somewhere, isn't
>> that right?
>>
>> musachy
>>
>> On Tue, Jul 22, 2008 at 7:49 AM, alvins
>> <al...@hotmail.com> wrote:
>> >
>> > +1 to remove.
>> >
>> > Valid points raised by all. I personally use JQuery in
>> my daily life and
>> > have written my own tags to do these functions. I did
>> previously look at the
>> > effort required to update the current tags to the
>> latest dojo but it would
>> > be very time consuming and far easier to start from
>> scratch. I think a
>> > large problem with the current dojo tags are that it
>> is very complicated to
>> > do simple things (dojo itself is complicated
>> relatively).
>> >
>> > With JQuery it is quite easy to do most of the things
>> mentioned so am not
>> > sure on the benefits of tags. That said - if you made
>> the tags powerful
>> > enough - they can be quite useful in a large number of
>> cases - however the
>> > flipside is as you add functionality, maintainability
>> becomes an issue.
>> >
>> > btw. If anybody is interested in some JQuery tags I
>> could start a plugin..?
>> > --
>> > View this message in context:
>> http://www.nabble.com/-PROPOSAL--Deprecate-or-remove-Dojo-plugin-tp18573704p18587222.html
>> > Sent from the Struts - Dev mailing list archive at
>> Nabble.com.
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail:
>> dev-help@struts.apache.org
>> >
>> >
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?"
>> Pink Floyd
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Dave Newton <ne...@yahoo.com>.
--- On Tue, 7/22/08, Musachy Barroso <mu...@gmail.com> wrote:
> I think Dave also had a JQuery plugin somewhere, isn't that right?
I can neither confirm nor deny the existence of said project.
I started to convert the Dojo tags to jQuery and stopped again pretty quickly; I only had <s:a.../> with a single target.
I started w/ the Dojo tag code, as I had wanted to make them as compatible as practical w/ the Dojo tags. My project then did everything via raw jQuery anyway, so they got put on hold.
To answer somebody else's question, I gathered JavaScript in a couple of different ways across projects, including keeping it in a ThreadLocal String then spitting it out with a tag or appending it via an interceptor (not sure that was HTML-compliant though).
I agree that having things like <s:a...> and an Ajax submit would be pretty nice--make the easy stuff drop-dead simple. Anything beyond that I'm less sure, and tying S2 itself to a particular client-side framework always worried me a bit.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Dave Newton <ne...@yahoo.com>.
One solution would be to provide the backing components for simple use-cases (like <sx:a...> and <sx:submit...> at least) and an integration with a couple JavaScript libraries, hopefully making it obvious enough that people could then implement their own back-end.
With simple components updating on backing library updates is easier, and (in theory) it makes it easier to understand how users can extend or create additional tags to suit their needs.
So I vote +1 for removing the existing Dojo plugin (+0 for deprecating) and +1 for creating the simplistic components and example integrations.
Dave
--- On Tue, 7/22/08, Musachy Barroso <mu...@gmail.com> wrote:
> From: Musachy Barroso <mu...@gmail.com>
> Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin
> To: "Struts Developers List" <de...@struts.apache.org>
> Date: Tuesday, July 22, 2008, 9:34 AM
> I think Dave also had a JQuery plugin somewhere, isn't
> that right?
>
> musachy
>
> On Tue, Jul 22, 2008 at 7:49 AM, alvins
> <al...@hotmail.com> wrote:
> >
> > +1 to remove.
> >
> > Valid points raised by all. I personally use JQuery in
> my daily life and
> > have written my own tags to do these functions. I did
> previously look at the
> > effort required to update the current tags to the
> latest dojo but it would
> > be very time consuming and far easier to start from
> scratch. I think a
> > large problem with the current dojo tags are that it
> is very complicated to
> > do simple things (dojo itself is complicated
> relatively).
> >
> > With JQuery it is quite easy to do most of the things
> mentioned so am not
> > sure on the benefits of tags. That said - if you made
> the tags powerful
> > enough - they can be quite useful in a large number of
> cases - however the
> > flipside is as you add functionality, maintainability
> becomes an issue.
> >
> > btw. If anybody is interested in some JQuery tags I
> could start a plugin..?
> > --
> > View this message in context:
> http://www.nabble.com/-PROPOSAL--Deprecate-or-remove-Dojo-plugin-tp18573704p18587222.html
> > Sent from the Struts - Dev mailing list archive at
> Nabble.com.
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail:
> dev-help@struts.apache.org
> >
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?"
> Pink Floyd
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by Musachy Barroso <mu...@gmail.com>.
I think Dave also had a JQuery plugin somewhere, isn't that right?
musachy
On Tue, Jul 22, 2008 at 7:49 AM, alvins <al...@hotmail.com> wrote:
>
> +1 to remove.
>
> Valid points raised by all. I personally use JQuery in my daily life and
> have written my own tags to do these functions. I did previously look at the
> effort required to update the current tags to the latest dojo but it would
> be very time consuming and far easier to start from scratch. I think a
> large problem with the current dojo tags are that it is very complicated to
> do simple things (dojo itself is complicated relatively).
>
> With JQuery it is quite easy to do most of the things mentioned so am not
> sure on the benefits of tags. That said - if you made the tags powerful
> enough - they can be quite useful in a large number of cases - however the
> flipside is as you add functionality, maintainability becomes an issue.
>
> btw. If anybody is interested in some JQuery tags I could start a plugin..?
> --
> View this message in context: http://www.nabble.com/-PROPOSAL--Deprecate-or-remove-Dojo-plugin-tp18573704p18587222.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Posted by alvins <al...@hotmail.com>.
+1 to remove.
Valid points raised by all. I personally use JQuery in my daily life and
have written my own tags to do these functions. I did previously look at the
effort required to update the current tags to the latest dojo but it would
be very time consuming and far easier to start from scratch. I think a
large problem with the current dojo tags are that it is very complicated to
do simple things (dojo itself is complicated relatively).
With JQuery it is quite easy to do most of the things mentioned so am not
sure on the benefits of tags. That said - if you made the tags powerful
enough - they can be quite useful in a large number of cases - however the
flipside is as you add functionality, maintainability becomes an issue.
btw. If anybody is interested in some JQuery tags I could start a plugin..?
--
View this message in context: http://www.nabble.com/-PROPOSAL--Deprecate-or-remove-Dojo-plugin-tp18573704p18587222.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org