First and foremost, I totally agree that we should avoid to have a
driven-by-excitement attitude on this topic, and develop a reasonable
consensus and plan. See further comments inline
Martin Cooper schrieb:
I'm here, and I've been following along. I just haven't had time to
consolidate my thoughts until now.
First of all, I hope everyone recognises that it's by no means my call; it's
the team's call.
The subject of Ajax tags in Struts 2 has been hotly discussed over a period
of years. At different points in time, different bases for such tags have
been the hot favourite, from custom code through Dojo to jQuery, with a few
other stops in between. Some of the work has happened here and some has
happened elsewhere.
As far as I recall, the main discussions were:
- as we have a Dojo 0.4 integration, can we migrate to 0.9 (at that
time)? Turned out to be that that would be more sort of a rewrite than a
migration, and nobody was stepping up to do this - not only for limited
resources, but also for technical doubts about the framework regarding
it's API stability, performance, programming model and adoption rate.
- Could AJAX framework x be integrated? Every once in a while, this
question arose, and the most mentioned candidates for x were Prototype
and jQuery AFAIR
- Closely related to the former question: If we add support for another
n AJAX frameworks, would we want to to design an abstract API to have
the same tags with an easy to switch implementation done with user's
AJAX framwork of choice? Although I once was a firm supporter of this
idea, it turned out to be hard to realise because the frameworks
extremely differ in their architectures and programming models.
IMO, there are basically two feasible ways to go: define a base tag api
and components, that every AJAX tags plugin is required to implement
(along with consistent core attribute naming and behaviour). On top of
that, allow the plugins to have their special feature stuff - similar to
JSF in that case. The other way to go could be: If the user decides to
go with strut2-[AJAX framework x]-plugin, he will most likely not switch
to framework y during the lifetime of his project, so just develop
plugin x and y independently to fit best the underlying framework's
architecture and capabilities.
Again, that's what I recall from the last years - anybody feel free to
chime in and add, correct or discuss.
From my perspective, it is critical, in adopting any set of Ajax tags as a
baked-in part of Struts, that we, as a team, are fully convinced (a) that
the underlying toolkit is not just the flavour of the month and will last
for years to come, and (b) that we have a sufficient body of developers
committed to making it work today and keeping it working years from now. And
I do mean years here. Certainly the world will change, and the world of
highly interactive web apps will change. But think about this: Struts 1 was
first released 9 (nine) years ago, and many thousands of web apps that were
built on it are still running, and being maintained, today. I'm sure we
would all like to have that level of success, and longevity, with Struts 2.
It takes commitment, though.
Totally agree. As for the flavour of the month aspect, I would add that
jQuery should IMO be considered to have overcome this stage.
I do take issue with a few statements that have been made in this thread
about Ajax toolkits. Rene said that we can consider Dojo "the biggest
loser". Can we really consider a toolkit that has seen corporate adoption
from the likes of IBM, Sun, AOL, Google, Nexaweb, and numerous others, "the
biggest loser"? Some people here may not like to work with it, but Dojo is
one of the biggest success stories in the Ajax world. That's not to say that
jQuery has not had its successes - and, as Wes points out, has seen adoption
by Microsoft - but jQuery is still a long way from "the" Ajax framework that
Rene asserts.
OK, let me clarify here. I regard Dojo as the biggest loser not because
it's generally bad or not adopted. It's because of the mismatch between
claims and reality here. If you look at the Dojo supporting committee,
it looks like a who is who dictionary. Just to mention a few: IBM, Sun,
BEA, Redhat or Zend. But what was the outcome? One would expect that
with such a huge supporting group, the progress should be fast and the
documentation should be good. Actually, the development towards
something regarded as stable took ages, and the documentation was
extremely poor (which may have changes nowadays). The line ending in 0.4
line was around for one or two years AFAIR, when it was decided that the
framework has to undergo a major refactoring towards the 0.9 line, which
was not compatible with 0.4 any more. Many early adopters were facing
the fact that moving to 0.9 would be as painful as reevaluating the
other frameworks now around and possibly switch to one of these, and a
lot of them did so. Although Dojo was one of the first movers to provide
an AJAX framwork, they turned out to be one of the latest to declare a
stable release.
I totally respect that having an 0.x release usually indicates that the
API is likely to change, but I would expect to have a reasonable
timeframe then for early adopters to get a maintainable production
quality release - especially for a project not only with this many
contributors, but also with contributors getting paid for their work as
their employer sees the framework as a strategic product. Actually the
development of Dojo started in 2004-2005, and the 1.0 release was in
late 2007. By this time, jQuery 1.2 and Prototype 1.5.1 were already
released. Given the claim and the impressive supporter list of Dojo,
this is what I call being a big loser.
As for adoption, although far from representative, here are two
interesting links comparing a couple of JS frameworks:
http://royal.pingdom.com/2008/06/11/javascript-framework-usage-among-top-websites/
http://www.kylehayes.info/2009/03/29/survey-results-javascript-frameworks/
For me it looks like, in spite of the good intentions of an impressive
committee, the users have voted with their feet. Dojo's actual relevance
is quite poor, and that's the second reason why I call it a loser
(again, compared to it's claims). IMO Dojo is a great example that
design-by-committee can have it's downsides...
That said, the above is not an argument against the adoption of jQuery as
the basis for Struts 2 Ajax tags. It's merely my attempt to bring us down to
earth a little bit in our enthusiasm to jump on jQuery and ditch Dojo. Each
has its merits, as do other alternatives.
As for ditching Dojo: Actually, we already did when we put it into
maintainance mode. In respect to what state Dojo has now, I would not
say we really do have a Dojo plugin - we do have an AJAX-features tags
plugin based on an early Dojo version. Of course we need to keep it for
backwards compatibility.
So, assuming the general concensus is to move forward with integration of
Johannes' tags, what are the next steps?
1) Musachy hit the nail on the head when he said "I would like for us to
define some strategy for this". It's crucial that we define, up front, where
we want to go with this. What should the Ajax tags include? What should they
specifically _not_ include, which is at least as important? Do we still
believe that what we want is a set of simple tags and nothing more? If not,
why not? How much coupling - that is, loose or tight - do we want to live
with? It would be great to see some (more) discussion of this kind of thing
up front, and perhaps the concensus documented on the wiki for all to see
(and abide by).
2) Once we've agreed on the major points from #1 above, we can take a
clear-headed look at what Johannes has done and assess how well it meets
those needs. What would need to be added? What should be removed, to keep it
streamlined to our objectives? We should be sure that we're not jumping on
the "cool" factor, and have something that forms the basis for our needs.
Agree, and great to see that Musachy already set up a Wiki page for
that. But we should also incorporate and respect the S2 users' view the
best way possible. Now that Johannes' plugin is out, it will get hard to
keep things "under control", given the assumption that we will have a
lot of S2 users starting to adopt the plugin very soon. Our timeframe to
canalize this is IMO quite short. What I suggest is that, given that we
would have a consensus to incorporate a first class citizen plugin based
on Johannes work backed by our first impressions of the plugins' code
and functional quality, we should move it to sandbox even before we
start major architectural discussion and detailed planning. That would
have the following, IMO important, effects:
- provide an early and clean integration point from a build management /
Maven perspective for early adopters
- we would clearly signal that although the original work is declared
1.0, users should not directly use it but rather use the sandbox
project, with clearly stating that they have to see themselves as early
adopters of a moving target
- incorporate early adopters' feedback soon and canalized via the Struts
lists
Nevertheless, this would assume that we manage to find a solution for
Martin's point 4) below.
A side note regarding architecture: We should have a close look to the
new JSF 2.0 versioned resource management system which was especially
designed to integrate cleanly separated versions of the JS frameworks
the JSF implementors want to provide and to overcome problems in managed
environments such as Portals. We had big troubles with Dojo in that
aspect, and we should try to do better for the plugins to come.
3) If we're going to bring Johannes' code into Struts itself, we need an
iCLA, and personally I would prefer to see us use the IP Clearance process
to make sure we're all squared away. Johannes' iCLA is on file already. The
IP Clearance process is intended to be straightforward and quick, so it
should not be an issue.
4) Musachy does raise an excellent question regarding commit rights and the
sandbox. We have not hit this exact case before. Obviously we'll need to
figure this one out.
One final point: I recognise and understand the enthusiasm that's behind the
"let's get it in here now!" sentiment, but really, we're not in a huge big
hurry. Let's take the time we need to think through where we want to take
this, before we head of down the road with it. A week or two here or there
won't make any difference in the long run, but poor decisions will.
[snip]
A week or two (or even three or four :-) ) is fine, but we should have
in mind that things can get out of our hands soon if the progress is
lazier than that. That being said, I totally agree with Martin's point here.
- Rene
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
