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]
