Roger Ye wrote:
Hi Frank,
I'm interested in the experience with DWR and Dojo you have got,
so why are you trying to move away from Dojo? then move to which?
is is DWR?
Let me begin by giving the caveat that we started with Dojo 0.3.1, and
have never had the time to upgrade, so we're still on that version.
We've also had to make quite a few custom mods (not just a custom build,
actual Dojo code changes) to it to get it to do everything we needed,
which makes upgrading that much harder. For reference, we're using
dojo.io.bind, plus some widgets (tab, calendar, button, floating pane
and menu). We used to use the button widget too, but swapped that out
for performance reasons, believe it or not!
We're moving away from Dojo because of one realization: it's better to
build with best-of-breed products than to try and grab one do-it-all
product. We choose Dojo initially for two reasons. One, it was gaining
a lot of steam at the time we made the decision, and two, because of the
nature of our development team (they had no RIA development experience
and didn't have a ton of Struts experience either), we felt it would be
better to have one library that did everything we needed. We decided we
wanted to use Struts (1.2.7) because there was at least *some*
familiarity on the team with it, so we needed to find some method of
AJAX that could co-exist with it, so DWR wasn't the best choice at the
time either. And really there was a third reason: there was no dominant
Javascript/AJAX library really, but Dojo seemed to be on its way to
becoming that (and still may be), so there really wasn't a *whole* lot
of choice, given some of our challenges.
And since someone is bound to ask, we considered AjaxParts of course,
would be crazy if we didn't consider the project I started! We decided
against it because the nature of the app we were charged with building
would have required a ton of custom handlers to be coded, and when you
get to that point, the benefits of APT start to melt away.
We had our problems with Dojo along the way ranging from performance to
bugs to missing features. But again, to be fair, we're talking about a
fairly old version at this point. We overcame all of these, and the app
is very highly regarded now, so the choice hasn't actually hurt us in
any big way.
The drive towards DWR is coming from me specifically because it starts
you down a path of an architecture that makes a ton of sense to me:
best-of-breed widgets and support libraries on the client, and nothing
but POJOs on the server. No framework like Struts to learn, no
complicated Javascript to learn (at least for the remoting part of the
equation) and very quick turn-around times because writing a POJO is
quicker than anything Struts can offer (and the less said about EJBs,
even 3.0 beans, the better). Mix in the right widgets and you can get
an incredibly rich webapp up and running in almost no time at all.
I'm also introducing Spring to a lot of people little by little (and
learning it myself little by little), as part of our developing
reference architecture, so we get a lot of benefit there too, and it
integrates nicely with DWR.
We're finding that a lot of the things we thought would be problems,
like the desire to have method-level access control like you get with
EJBs, is not much more work in this model. There are still some
challenges of course (like not having il8n automatically like you can
have with Struts), but overall it's working out very well.
I've used DWR in a previous project, for me it's quite good, gotta love it,
however, in the current project we use Struts 2 and Struts 2 seems to have
some connection with Dojo, so I appreciate a lot if you could share your
story with Dojo.
I can't talk intelligently (as if that ever stops me!) about the AJAX
support in S2 because I only have some "playground" experience with
it... I've yet to use S2 in a real project that wasn't contrived for my
own benefit... then again, with this simple DWR-based architecture
gaining steam, I may never have to. Ironically, S2 does a lot of what
we did in our project: abstracts away the details of Dojo. We pretty
much built an API around Dojo so that our more junior developers barely
knew they were using Dojo. Some of this was taglibs (especially where
widgets were involved), other parts of it was a Javascript API that is
more business/function-oriented, so for instance, instead of having to
worry about how to do an AJAX call with Dojo, you instead call our
submitFormTargetTab() method, and that would deal with all the details
and put the results in the specified tab on the screen (plus it deals
with a lot of other related things that don't have to do with Dojo).
Well, that's my .0006 cents on things.
Thanks
Roger
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
