Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

DWR 2 and MVC web frameworks

 
Ranch Hand
Posts: 125
1
Clojure Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Mr. Zammetti,
I see from the DWR 2 site integration page: ( http://getahead.org/dwr/integration ) that DWR integrates with Rife and Struts 2, among other projects.

1. I take it, then, that DWR 2, alone, is not a full MVC framework. Is that correct?
2. Do the example application in your book use DWR 2 alone, or do they use any other frameworks to fill in some of the details?
3. If you use DWR with other web application frameworks, would you care to briefly explain which ones you prefer and why?

Thanks.
 
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Ok, while I have a few minutes during the day I'm going to try and answer a few of these questions sooner than later, starting with this one because I like it a lot myself

It's correct Michael that DWR is not itself a full MVC framework... I'd say it really only represents the controller portion of such an architecture.

The examples in my book use DWR alone, I don't examples of integration with Struts for example, largely because I just don't see that integration as being very valuable. What DWR offers in this regard doesn't seem terribly useful to me, but it's more than that, and that goes into an answer for your third point.

I have a very strong opinion that has formed over the last year or so of experience with DWR that DWR *by itself* is all the framework anyone needs. More to the point, it leads to much cleaner and simpler code, and a lot less of it.

We built a highly complex app at work on top of Struts. We then began rolling some DWR into the mix. What we found is that the parts built with DWR was just plain better in terms of what we had to write, how much we had to write, and how easy it was for junior developers to grasp it. The Struts parts hy contrast, largely using Dojo's AJAX functionality on the client, was just plain too much work. Now admittedly that's Struts 1, but I've done some proof-of-concept wotk with Struts 2 as well and it's almost worse in many regards.

DWR, as I say in my book, is a paradigm shift, if you let it be. What I mean is that it leads you down a path of doing everything with POJOs and really decoupling the client form the server as a consequence (maybe an indirect consequence, but a consequence none the less). You wind up with something a lot closer to a true SOA, although obviously it's not, it's RPC-based, but you start to say "ok, let me create my simple API, and then the client is just calling it". It really completely gets you away from that page-request-new page paradigm that most MVC frameworks push you down.

In fact, I've had conversations with some people about actually starting up a new project that takes DWR and literally builds a whole framework around it to compete with Struts and all the others out there. If it wasn't for a lack of time thus far I would have had this off the ground already! But that's where I think things should be going frankly, *not* tighter integration with these other frameworks because instead of simply filling the whole as you suggest, DWR in fact makes all the rest quite superfluous IMO, and in many ways it's actually counter-productive to try and make such integration work.
 
Michael Swierczek
Ranch Hand
Posts: 125
1
Clojure Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Thank you very much for the thorough response.

So when you write that you eliminate the rest of the MVC, doesn't that muddle your code? Or do you mean that you eliminated a framework, but you still keep the stuff doing presentation work separate from the pieces that handle business logic and persistence?

I got into Java web development at a company with a Struts 1 application. It worked, and the coding and architecture that the original creators built around Struts was very nicely done. (At least, as far as someone new to the field like me could tell.)

But Struts itself, along with JSP/JSTL (and of course, HTML, CSS, and Javascript) and the normal host of XML and .tld files is not, in my humble opinion, geared towards easy learning or easy modification. Coming from a C/C++ background - and quite honestly, I wasn't even a particularly good C or C++ developer - picking up Java was child's play. Learning the basic material in the Sun Certified Web Component Developer Exam was many times as much work. I know some IDEs automate tedious portions of the development process, but even then adding screens and features is tremendously more time consuming than, say, adding a new screen to a regular Java application.

I'm comfortable enough with Struts 1 that I can land a new job with it. But I would prefer not to use it. I'm been hunting for a related skill set that can balance getting a good job with working on efficient and intuitive skill sets. Maybe this is it. I've looked at Struts 2, and it looks like a dozen improvements to Struts 1 but enough of a learning curve between them that much of the advantages are negated. (I mean no disrespect to anyone working on the project. I'm sure after a few months I would be much more productive with Struts 2 than Struts 1. But it's not the Amazing Revolutionary Improvement I was hoping to find.)

Thanks again for the food for thought.
 
Ranch Hand
Posts: 948
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Frank:

Thanks for the thought provoking response! I am a Struts 1.x developer. I have looked at some other MVC frameworks and my thoughts seem to match up with some of Michael's. Other MVC frameworks seem to be better than Struts but nothing revolutionary. They all seem to be built around the "fill out a form, submit the page, refresh the page" mentality. The same type of thing for non-Java frameworks...they just let me create the same crappy web pages faster. GWT is about the only thing that looks really exciting (I need to spend some more time with GWT).

Your comments about using DWR to get rid of the MVC model sounds very interesting. I was developing much better user interfaces in VB and C++ 10 years ago and I can see that it will not be long before we get back to creating easy to use, rich interfaces that are not chained down by the limitation of browsers and html. Right now that seems to involve a lot of CSS and JavaScript. While this is not my favorite mix of technology I can live with that. I might just have to look a little closer at DWR to see how I can move beyond the request/response cycle.

- Brent
[ March 11, 2008: Message edited by: Brent Sterling ]
 
Sheriff
Posts: 67753
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Just make a few clarifications, especially for those less versed in web applications:

Originally posted by Brent Sterling:
I was developing much better user interfaces in VB and C++ 10 years ago

Any web toolkit or framework isn't going to allow you the full range of UI available to desktop applications. They still run in the browser and are still bound by the limitations of DHTML and HTTP.

back to creating easy to use, rich interfaces that are not chained down by the limitation of browsers and html.

Again, be it DWR, GWT or whatever else you may choose to employ, they don't magically make the browsers do anything they're not already capable of. What they may do (and I stress "may" because I find many fall short of their promises) is to create wifty UI's based on DHTML without you having to write a bunch of HTML, JavaScript, and CSS. But when it all comes down to it, it's still DHTML and HTTP.

I might just have to look a little closer at DWR to see how I can move beyond the request/response cycle.

DWR is still bound by the HTTP request cycle; it just cleverly uses Ajax to help your code pretend that you're not.

Not trying to dash anyone's dreams here, but just wanted to make sure that no one gets the impression that these tools turn the browsers into something that they are not.
[ March 11, 2008: Message edited by: Bear Bibeault ]
 
Frank Zammetti
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
For me, what I'm finding is that you can still maintain the separation you're looking for from a "classic" MVC framework, but things kind of shift around a bit

What winds up happening is that your view and control layer migrate down to the client, while your model of course stays on the server.

It's also worth noting that MVC was a pattern devised back in the heavy Swing days, it wasn't originally a web framework paradigm. Some even argue that Struts, and most other "MVC" frameworks, in fact are nothing of the sort. I'd rather not get into a complex CompSci debate on that point though

DWR blurs the lines between what runs on the server and what runs on the client. If you forget for just a moment, as it's easy to do with DWR, that your code is running in two different places, you start to ask yourself "what does MVC actually MEAN in this context"? It's the same as asking what MVC means in a Swing application, when all the code truly *IS* running in the same place. You can still do MVC, but all the layers are essentially in the same place. By extension, having the view and control code out on the client while the model stays on the server doesn't hurt my head
 
Michael Swierczek
Ranch Hand
Posts: 125
1
Clojure Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Bear Bibeault,

I can't speak for Brent Sterling, but I did not mean to give the impression that DWR or any other Java toolkit I'm examing removes the need for DHTML, CSS, and Javascript.

I just meant that some of the available toolkits may make the automated creation of DHTML/CSS/Javascript much easier. A very good one might make automated code creation easier, and also make it straightforward to me to extend the automatically generated items with additional options.
 
Bear Bibeault
Sheriff
Posts: 67753
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
I did not think that you did. My response was to Brent's post, which when read by someone who has yet to wrap their brains around how web apps work, might be construed incorrectly.
 
Brent Sterling
Ranch Hand
Posts: 948
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Not to get too far off topic but maybe it is about time to change how we think about "how web app work". Whether having desktop-like web application (like Gmail) running in a browser is a good thing or not is debatable, but there sure seems to be a movement towards that type of application. I understand the basics of DWR and I know that it is not a magic bullet (and it is not a user interface widget library).

Many moons ago I was involved in a servlet based reporting package that streamed Java objects between the browser and the server (based on examples by Jason Hunter). There was a bit of plumbing involved and there was the overhead of serializing objects, but it was actually a pretty powerful mechanism that blurred the lines between the client and the server. I could see how it would be useful to have a technology like DWR that brings some of these concepts to JavaScript development.

- Brent
 
Bear Bibeault
Sheriff
Posts: 67753
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Originally posted by Brent Sterling:
Whether having desktop-like web application (like Gmail) running in a browser is a good thing or not

You'll get no argument from me. The financial web app I work on in my day job was specifically designed to resemble a desktop application as much as possible.

Again, my point was mererly that such applications still need to work within the confines of current technology.
 
Ranch Hand
Posts: 1327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
does DWR 2 provides support to integrate with the latest version of Spring and Sun's JSF? are there examples in the books that show integration with various popular open source framework and even commerce products ?
 
Frank Zammetti
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
I'm not sure if DWR integrates with the LATEST versions of Spring and JSF, but it does offer integration with both.

I also don't think there's very much value in this integration. Having Spring create your remotable classes is fairly nice, but aside from that, the integration didn't, and still doesn't strike me as very useful. As such, I talk about it in the book fairly briefly and don't actually show it in use.

Then again, they couldn't have paid me enough to write positively about JSF, but that wasn't your question I suppose
 
Bear Bibeault
Sheriff
Posts: 67753
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Originally posted by Frank Zammetti:
Then again, they couldn't have paid me enough to write positively about JSF, but that wasn't your question I suppose

Oh, I knew I was going to like you!
 
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
quite an interesting discussion...

I started reading about DWR few days back. Its strikingly different from the usual web-app technologies I have worked on till date (read as huge amount of Struts). One question that invariably comes to mind is can DWR really replace MVC ?
One may argue about the usability of MVC but the more mature frameworks like Struts and JSF give lots of tools in the MVC. Validation, interpretors(struts2) etc..

From whatever I have understood about DWR from my little reading and if I can put it down in few words is that its nothing but say 'RPC over HTTP'. so, Can we really replace a MVC architecture with DWR ?
 
Bear Bibeault
Sheriff
Posts: 67753
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
This would a better question to post as a new topic in the app frameworks forum. Not only is this topic over a year and a half old, DWR is better discussed in frameworks.
 
Aaaaaand ... we're on the march. Stylin. Get with it tiny ad.
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
    Bookmark Topic Watch Topic
  • New Topic