WOW!! > -----Original Message----- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: 03 December 2005 22:12 > To: Struts Users Mailing List > Subject: Re: Integrating Struts in DWR?? > > > Some of the questions you ask here are really more for you to > decide... > there aren't any canned answers. That being said, I'll do my best... > > To begin with, I highly suggest checking out the numerous articles on > AJAX out there to get a firm grasp on what it really is, and > if I may be > so bold, start with my own: > > http://www.omnytex.com/articles > > This will show one way AJAX can be integrated with Struts. > You can also > check out my AjaxChat example app on the Struts Apps SourceForge site: > > http://struts.sourceforge.net > > The short answer is that AJAX, generically, is nothing but an HTTP > request. As far as whatever is on the server is concerned, be it a > Struts apps or something else, it doesn't look any different than any > other request. Well, I suppose more accurately, it doesn't *have* to > look any different. If you simply pass simple parameters from the > client and forego XML, then to Struts there's no difference. >
Right, If I understand what Frank is saying then this is a HTTP Servlet that just parsing the input request, which is XML and generates a response which is also XML. As some one also working in the ``banking environment'' I can see the value for helping the spreadsheet users entering forms. The Google Suggestive or autocompletion is a real good usecase for my client. For instance I want to enter ``Barcl'' and then get a drop list of including ``Barclays Banks, Great Britain'', ``Barclays Capital Management'' etc > If you want to use XML and Struts, then you will at this > point have to > do your own parsing. With Struts 1.3, it would be trivial to add a > Command to the processing chain to parse an incoming XML message and > translate it to request parameters... come to think of it, > that exists > already: > > http://sourceforge.net/projects/strutsws > > Although that's for Web Services, the underlying theory is identical. > There is a 1.3 version, courtesy of Marco Mistroni, but you > can see my > original version with the customized RP. The same thing would work > nicely for AJAX, although one can envision other ways of doing it too. > So basically if you architectured your application correct, and pushed all or most of the logic to the business delegates or facades then it should be easier to add AJAX server side. Essentially to do the Google suggest thing for my perspective is that you have cache on distincts e.g ``SELECT DISTINCT(CONTACT_NAME) FROM EXTERNAL_REFERENCES''. You store the results in a sortable collections for a user session or ORM cache. Do this for all the input fields for your input forms that want to add the suggest feature The AJAX server method just filters on the string input from the html text fields and returns the XML result set of possible matches. > You could just as well have this function in your servlet... > it's just a > matter of getting the body content of the HTTP request, which > would be > XML, parsing it and doing what you'd always do. If this > interests you, > have a look at the code in CVS HEAD here: > > http://javawebparts.sourceforge.net > Frank I thinking of implementing the Google suggest concept for my client for a ``big form''. Is your subproject up to it? > I'll probably cut a release this weekend, but the code in CVS for the > AjaxTags component in the sample app does exactly that... an AJAX > request is made with XML in the HTTP body, and a servlet in this case > gets it (via the handy RequestHelpers.getBodyContent() > method) and then > uses Digester to parse it. > Does your current version handle simple or complex XML documents? Should I wait for you release? > Everything I've talked about here is "naked" AJAX, i.e., without the > help of any particular library. AJAX is really quite simple, > aside from > a few gotchas, but there are some very robust libraries that > will help > with more than the basics in most cases. They all seem to have a > slightly different focus from one another, so if you'd prefer > to go that > route, some (of the many!) to look at are: > > http://javawebparts.sourceforge.net/javadocs/javawebparts/taglib/ajaxtags/package-summary.html > > > This is the AjaxTags component of Java Web Parts... this is a little > different than the rest in that it makes enabling specific > events very > easy. All it requires is adding custom tags to your page, and > configuring various AJAX events via XML config file. For > instance, if > you want to fire an AJAX event when a <div> is clicked, and then you > want a function that will populate another <div> from what the server > returns, this is a trivial exercise with AjaxTags, and it's > all driven > by config file so there is no coding involved, aside from > adding a tag > or two to your page. This is my own creation, so obviously > I'll push it > a little more than the rest, but I truly do believe it offers > something > than most other options do not and you probably should at > least check it > out and see if it meets your needs. > > http://dojotoolkit.com/ > This is the one people are starting to really get behind, and > from what > I can see there is good reason for it. This is one of the ones that > will give you more than just AJAX, and that might be very > appealing to you. > When I surf there a week ago they did not have any real life example and I have just gone there now, ... and they still dont have real examples. I think this is because it is still V0.1 and requires knowledge of JavaScript. You can play with the unit tests http://archive.dojotoolkit.org/nightly/tests/ and the rich text editor http://dojotoolkit.org/docs/rich_text.html work nicely on the standard Internet Explorer here. If you want to get into heavy AJAX then it is worth listening to Ajaxian.com on the podcasts. > DWR of course you already know about. > > http://prototype.conio.net/ > Prototype is actually more of a foundation as there are other > libraries > that use it. So certainly check out some of those libraries, but > Prototype on its own might be something you want to use. > > There is no canonical answer at present for integrating with > Struts, but > the point is there probably doesn't ever have to be one... > it's just an > HTTP request. Oh, there could be something added to Struts to handle > automatic parsing of XML and stuffing it into an ActionForm, > that might > not be a bad idea, but since you have access to the request object > anyway in an Action, you can do everything that Struts would > ever do for > you so it would probably be unnecessary to add it to Struts. > > To the question of whether AJAX is appropriate or not... > first, from a > security standpoint, AJAX is no different from every form you submit, > every window.location call you make, every image you GET, > etc. The same > security concerns that arise in those instances are present > with AJAX. > AJAX has a limitation in that it can't make requests to domains other > than the one that served the page it's on, so in a sense it's MORE > secure. But the bottom line is you secure AJAX the same way > you secure > your webapps generally. > > If your wondering if it's worth it, that of course is for you > to answer. > There are some cases where it absolutely makes things > better, but it > comes with some baggage... unless you spend a lot of time > worrying about > graceful degredation, your app will now *require* scripting. > This might > not be a problem for you, but it might be. AJAX is also a > problem for > accessability. In some cases this is a major problem, but even when > it's not it's something we should all think about. It also > raises the > level of expertise your app requires to maintain. > > I'm personally a fan of AJAX. I've been doing AJAX for over 5 years > (keep in mind that AJAX is really more a philosophy and an > approach than > it is any specific technology... I haven't used > XMLHttpRequest for very > long, but I accomplished the same types of things in an app 5 years > ago). I believe the age of the "classic" web, where scripting is > optional and apps redraw entire screens, is dead. AJAX itself is > nothing knew, but the mindset that accompanies it largely is, > so if your > asking *me* if its a good idea in the first place, I'd say absolutely > yes, assuming two things... first, that the way you want to apply it > makes sense; anything can be used in a pointless way of course!, and > second, that you understand and can accept all the caveats > that go along > with it. > > Hope that helps! > > Frank > > Sonali Kulkarni wrote: > > So, does it mean that is it not a good idea to use DWR with > Struts just as > > yet? > > > > If so, what would be the best way to integrate AJAX into our Struts > > application? > > > > Ours is a full-blown *financial* banking Struts > application. Please also let > > me know if it is a good idea to use AJAX in the first > place, considering (1) > > the security risks imposed, especially for a financial > application (2) ease > > of integrating AJAX with Struts. (some of the questions i > have, for starters > > are... how do i pass the request object from the javascript > to my action > > class method, ... how do i handle errors returned etc) > > ==////== -- Peter Pilgrim :: J2EE Software Development Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.csfb.com/legal_terms/disclaimer_external_email.shtml ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
