Ken Bowen wrote:
Frank,
This may be too far off-list; if so please suggest another channel.
However, there may be other developers lurking on the list who would
also be interested.
I'm sure there's a better place, but I'm not sure where it would be. I
agree, it's a question others may have interest in here... in a way, a
list for Tomcat almost necessarily brings up other tangential topics
like this :)
I've downloaded DWR and performed a cursory look through the examples,
and it looks
promising (I've done a chunk of very bare-metal ajax, and a chunk of
GWT).
I've also read your blog entry on the subject and am quite convinced
about the desirability of
an RPC-like framework. What I don't have a feel for is the mix
between ordinary html and
javascript that might be forced on you by DWR.
I have a major application at work that I've been involved with for
nearly two years now... it's a really interesting case study I think.
I'll frankly have to be a little careful what I say here because it's a
back-office application that gives us a pretty good competitive edge,
but we're a little secretive about it unless you're a client, or
prospective client (not entirely sure why)... I'll try to get the basic
gist of it across though...
The underlying concept is we have a single application that essentially
houses a host of others. I hesitate to use the term portal to describe
it, and it most certainly does NOT use portal technology, but
conceptually that's along the right lines. It's a highly complex RIA,
I've said for some time I'd put it up against any out there in terms of
complexity. It really does take the notion of a webapp that looks,
feels and functions like a traditional fat client to a high level of
realization.
Now, when we started this project, we were handed a fairly inexperienced
team, certainly when it comes to RIAs. So, we had some early choices to
make to try and make things as easy for them as possible. Because they
had some experience with Struts, we went with that. Early on we showed
them how you could have Struts return JSON and make Ajax requests to get
it (duh, who'da thunk you could render JSON in a JSP?!?). So, when you
hit the initial URL, you do a fairly typical Struts-type load, i.e., you
have some tiles that get populated, some Actions that execute, and you
wind with up a final rendered HTML page on the client. This essentially
is the shell of the application where "modules", so to speak, can be
plugged into.
After that, nearly everything that happens is Ajax-based, and Struts
becomes little more than a router for requests. We rarely ever return
HTML from the server after that initial load, and only in one or two
special circumstances to we reload the HTML page initially loaded into
the browser (think security situations).
Now, here's where it gets interesting... over the last year we've been
expanded the capabilities of this application at a phenomenal rate...
it's the typical "oh look, that project was a huge success, I want in!"
kind of situation... everyone's got uses for it now! However, we've
started to migrate away from Struts entirely because it wasn't really
buying us anything. Conceptually what we had was an API (implemented as
Action/JSP combinations) that did some work and returned data (again, in
JSON form). This works well enough, and some people really like the
approach because it's in many ways the realization of an SOA model. If
you map the URIs properly you can have the REST interface everyone
clamors for without too much work.
However, we came to realize that what we were really doing was building
an HTML-specific abstraction in front of our API. Why not hit the API
directly? That's where DWR came in, and we've been quickly migrating in
that direction ever since. All new development is done this way, and
we've realized all the benefits I mentioned earlier.
DWR doesn't force anything on you per se. When you have some HTML in
the browser, you also have some DWR-generated Javascript. This is
nothing but a think proxy representing some Java objects that execute on
the server. You call a method of an object in Javascript, and
transparently DWR makes an Ajax request to the server, to the
appropriate object, executes the requested method, and returns the
result. This result is the same kind of result that you'd get if you
called the method directly in Java. What DWR does is marshals the
output of the method to a (roughly) equivalent Javascript form, and
calls your specified callback function. If the method returns a string,
you get a string. If it returns an array, you get an array. If it
returns a HashMap, you get an associative array. And so on.
Now, is there anything to stop you from having a method that returns a
string that is actually HTML? Nope, nothing. You could then take the
response as-is, inserted it into a <div>, and your page is updated.
That's perfectly possible. Is it the best way to do things? That's
open for debate, but I say no. If you write your Javascript to make use
of an API that just *happens* to be running on a server, you get a much
cleaner architecture IMO. But DWR doesn't force you to do things either
way, it's just a mechanism for executing remote procedure calls, nothing
more.
The item making me hesitant about sticking my big toe in the icy cold
water is this:
I'm looking at a couple of "legacy" struts 1.8 apps which need to have
some more powerful mini-apps
dropped into the pages without completely throwing out the existing
pages: think souped-up puzzles,
or souped up local database query or souped-up wizard-like expert
diagnostic action.
I'd hope to be able to at least preserve the tiles-based layout, and
even the fundamental
struts-control (constraining as I feel about that), just to cut down
on the extent of rework.
I told the above story because I think it's a good model for what you're
proposing... we started with a Struts-based application as well and
introduced DWR slowly but surely. The logical progression, to me, is to
do away with Struts entirely, but there's nothing to say you can't have
that intermediary step of mixing Struts and DWR. It's that "single
page" paradigm I talked about (somewhere) on my blog... at some point
you have to get the base HTML downloaded to the client, and you can
certainly use Struts for that. It's also often true, and it certainly
was for us, that you want to include some dynamic data as part of that
page. For example, we download some information about what roles the
user is in so we can customize the UI down on the client. Since this is
stored in LDAP, that initial load is a great place for that to occur.
I think you can certainly introduce DWR to your project in pieces, and
not have to rework much, if anything, of what you have already. I
personally wouldn't start a new project that way, based on my experience
with the application described here, but "retrofitting" it is fine. I
don't think you can effectively maintain "...the fundamental
struts-control" though... it would no longer be Struts' responsibility
to determine the next page to display, because there effectively would
never *be* a next page to display... but that's true of Ajax
architecture in general, it's nothing DWR-specific. However, you could
conceivably do the "return a string that's HTML" as I mentioned above
and get the same Struts-based control if you really wanted to. I'd
question why bother with DWR in that case though :)
I wonder if you would comment on this.
Comment... yes... comment COHERENTLY?... open for debate :)
By the way, I think I alluded to this earlier but it's probably worth
stating directly: the underlying concept I'm talking about here doesn't
necessarily rely on DWR... I just happen to feel DWR offers the best way
to realize that concept. At the end of the day we're talking about
API-based development where the API relies on the server while the
"application" resides on the client. I put application in quotes there
because how you define that term makes a big difference. Some will
protest that you're intermingling the view and the control layer and
putting it all on the client, but that's not the case. Those two layers
can absolutely be separate entities even if they happen to exist and
execute in the same place. Remember, MVC wasn't invented by Struts, or
even web application developers, it was around before that in the GUI
realm where fat clients in many ways combined *all three* layers in the
same physical location :) It's about a conceptual separation, not a
physical one.
Somewhere along the line we all got it in our heads that there has to be
some server-based process that determines what happens next in an
application. We decided the control layer *had* to be on the server.
That makes sense when the client isn't terribly powerful, or there's
such a huge disparity in what that client is that you can't count on
even some basic things. That's no longer the case, so maybe it's time
to start gravitating the other way again.
By the way, lest anyone thinks I'm advocating an insecure approach here,
doing things this way means you have to be perhaps *more* vigilant about
security... the usual parameter checking and such is extra important, as
is ensuring things are locked down as they need to be (DWR is good for
this: method-level permissions based on J2EE roles if you like). Some
people think this paradigm is inherently less secure because,
theoretically, someone can hack together some Javascript and own your
application. I don't believe that to be any more true than it is for a
more "classic" webapp. You've got to use your brain, and you've got to
fundamentally design with security in mind, but that's true no matter
what, right?
One last "by the way"... tou can achieve the same thing with a
REST-based architecture too. That's because a REST URL can in many ways
be related to a method signature. It's not a perfect 1:1 match, but
it's close enough to see how you can get to the same basic place in that
paradigm too. The difference is again that you're essentially putting
an HTTP-specific abstraction in front of your API. I'm never a fan of
abstractions unless you can show me there's a true benefit to the added
complexity. Sometimes you can convince me, frequently you can't :)
Some people are big-time on the REST bandwagon, and that's fine, I just
happen to feel DWR is better, if you're working in the Java space at
least.
Thanks in advance,
Ken
np,
Frank
--
Frank W. Zammetti
Author of "Practical Dojo Projects"
abd "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)
My "look ma, I have a blog too!" blog: zammetti.com/blog
On Aug 24, 2008, at 4:10 PM, Frank W. Zammetti wrote:
Being as most of what I do today is RIA development, I've personally
found that the ideal solution is to use NO framework at all. I use DWR
and just treat everything as method calls.
The nice thing about that is you wind up with a very clean and "plain"
structure to your application in the sense that you're thinking in terms
of classes and methods, like you do in general server-side anyway. It
also makes most of your application highly testable (except where
session comes into play, but we tend to try and minimize that usage
anyway). You design a proper API, and the fact that you're using it
behind a web-based application isn't really relevant (and in fact you
can truly slap any front-end on you want without much trouble).
I've found that my projects drift towards more of a component-based
model naturally doing this, and away from the classic page/action-based
model of Struts (which is where we were a few years ago). It becomes
much more about events, small, focused bits of functionality, and how
it's all put together to form a larger whole. The development cycle I
find is much faster, much simpler and the results are far more flexible
and extensible. It's in some sense a return to a more "bare metal"
mentality, but it's truly made our lives a whole lot better. I've had
to mentor some pretty inexperienced teams and I've seen this approach
versus the framework-centric approach with something like Struts, and
I've observed it to be much easier to get their brains wrapped around
this approach, they come up to speed and are effective faster, and they
are more effective than in cases where a full, "proper" framework was
used.
So, if the question is Struts vs. JSF, I'm in agreement with Johnny to a
large degree: neither is the best answer. And in fact, I second the "no
framework at all" opinion. I suppose if you wanted to consider DWR a
framework then I'd say DWR, but it's really just a mechanism, not a
framework (it could be something else other than DWR, so long as it
presented an RPC view of the world it'd be the same basically). But as
far as the "true" frameworks go, as we've come to understand them over
the past few years, my personal opinion is that they serve no purpose
any longer when talking about developing modern RIAs, and in fact tend
to get in the way more than they help in those situations. I completely
realize this isn't the popular opinion (yet), and many people actually
disagree quite vehemently, but I've had pretty extensive experience
building these types of apps for nearly 10 years now, and that's the
mindset I've come to at this point.
(I tend not to say this often, because it's usually annoying to me when
people do it, but what the hell... I actually blogged about this a
little while back: http://www.zammetti.com/blog)
Frank
--
Frank W. Zammetti
Author of "Practical Dojo Projects"
abd "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)
My "look ma, I have a blog too!" blog: zammetti.com/blog
Johnny Kewl wrote:
----- Original Message ----- From: "Tommy Pham" <[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
Sent: Sunday, August 24, 2008 7:03 AM
Subject: Struts vs JSF (poll?)
Hi everyone,
This maybe out of scope for this list but I wanted to know more about
Struts vs JSF other this old article [1]. Which are are deployed
mostly on your TC server(s)/cluster(s)? If any Java developers are
on this list, which platform API do you prefer for quick development
(to meet deadline), performance, security management (user
authentication and level restriction) etc... since both are based on
MVC despite their different implementations(?).
Since there isn't a JSR for Struts, has Struts been around before JCP
is formed? And why is there not a JSR for Struts now (just curious)?
As for JSF, which implementation is used by/for your app(s)?
Sun/NetBeans? Apache's MyFaces? or Others (please list)? I'm
somewhat disappointed Netbeans support for JSF and Struts in that
Netbeans bundled libs support used older Apache Commons lib version
(even for the current v6.1), although this could be updated but I
don't know whether it will break the integration of Netbeans' VWP.
Even the tutorial/trails on NetBeans site regarding Struts (although
this can be compensated at Struts' web site) is very limited perhaps
because of the (biased?) Struts weak integration to favor or push
more on JSF/Visual JSF?
I need to evaluate my options of API and IDE before I dedicate
several projects since the performance of Netbeans is getting worse
by every release comparing to Eclipse. As for server, I've decided
already ;)
TIA,
Tommy
[1] http://websphere.sys-con.com/node/46516
Use neither... prefer the plain TC MVC model.
Struts is really just an implementation of the MVC model in TC
JSF is more about trying to make web development feel like Swing
development... see Visual Web Pages in NB
Struts is very much a stand alone tool.
JSF needs the whole VWP framework to make it go.
Struts may not be a Sun standard... but Apache is a brand you can
trust... its generally all good free stuff.
JSF and VWP are Suns baby.
Sun and Apache dont see eye to eye on everything ;)
Netbeans is Sun
Eclipse isnt
You get the picture... theres some helthy competition out there ;)
The truth is... if you know what you doing, you dont need a
framework... if not a framework will get you going quickly.
Frameworks are cool until you want to do something outside of the
framework...
That applies to VWP or Struts...
If I had no other choice, I'd use Struts... but I'd also use NB ;)
Big problem with the NB JSF tools is the complete lockin... so if your
graphic artist is on Adobe, or FrontPage or anything else... they
going to hate you ;)
The NB JSF doesnt lend itself to multiple tools... its the swing way
or no way... or extreme pain when you need something from the outside
world;)
Its not about standards, its about lockin... actually many "standards"
also mean lock in... thats probably why they made them.
You cant beat just having a good clever designer on your team... there
are many in this TC group... hire one.
Also dont be a groupie... just think about the technology...
Trouble with that is the NB is cocking up trying to push glassfish
into it... but NB is Sun and Sun control Java... not a simple as its
just crap.
On the server end, there is a competition problem... on Java Core...
its hard to beat ;)
Being a Java programmer is full of hard choices;)
Have Fun.... and choose carefully... read up on the TC MVC model...
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__________ Information from ESET Smart Security, version of virus
signature database 3382 (20080823) __________
The message was checked by ESET Smart Security.
http://www.eset.com
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__________ Information from ESET Smart Security, version of virus
signature database 3383 (20080824) __________
The message was checked by ESET Smart Security.
http://www.eset.com
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.7/1631 - Release Date: 8/24/2008
12:15 PM
