I must have missed getting across what I was trying to convey... Basically the below was a proof-of-concept to show the same code that would be added to taglibs could be added to a javascript library and be freely distributed which would resolve the issues at hand. Then only the implementers would need to write javascript, everyone else would just need to learn the functions available and call the appropriate ones (and of course add the javascript include).
So as far as reading back a table, etc, etc. those can just as easily be a javascript api as a taglib update. The javascript api version would appear to give the same benefits for less cost from what I can tell so far. You would just need to instruct the user: if you need to replace inner html, call function a with the element to have the html replaced and the url to use to replaced the information. For an existing user, they're likely already calling a javascript function so they can re-direct from their own function in to the library as needed. Conceivably you could do the same for xml returns and anything else since we are talking client-side here. I haven't really used any of this ajax approach personally so I don't really know what kinds of "needs" people have when they are using it. Once the needs are determined it should be easy enough to write a good abstraction layer and I'd be willing to help there if this isn't something that's already planned by someone. I'd be interested to hear re: your ideas of handler types at [EMAIL PROTECTED] I'm moving this weekend (and have a newborn at home) so I'll be busy for the next week or so setting up and after that should have time to help out if it looks like something that I believe adds value. Regards...djsuarez -----Original Message----- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 20, 2005 4:31 PM To: David Suarez Cc: Struts Users Mailing List Subject: Re: AJAX: Whoa, Nellie! David Suarez wrote: > Saw the flood of these AJAX messages and was interested so I did a quick > test using a plain html page to see how easy it is to create a generic > javascript to handle the ajax call-back pieces in question. My test > showed it is easily possible so I'm not sure how much value you'll get > from creating another server-side component. Another javascript library > that wraps dojo would probably be all you need. If you consider a taglib to be server-side, than granted. Either way, the benefit is the fact that you don't have to write any code, even admittedly simple code. > > This is the general idea of the test I did in terms of the dojo/ajax > conversation: > > Generic Javascript function always included if you need to use ajax > (some javascript include that is added to the page): > > //updates the inner html of the passed object > updateInnerHtml(theobj, theurl) > { > dojo.io.bind({ > url: theurl, > load: function(type, data) { > theobj.innerHTML = data; }, //Note: "theobj" > variable is accessible here in firefox and IE... that was my test > mimetype: "text/plain" > }); > } That's fine if what you want to do is update innerHTML of something. But what if you want to take XML that was returned and populate a table? That is, I think you'd agree, more involved code. > Using the example, something like the below would be on the page: > <html:button property="button1" value="Click to do Ajax!" > onClick="updateObject(this,"http://xxx.yyy.zzz?a=b&c=d";)"/> And that works well if all your looking to do is submit a query string to a URL. If you want to do something more complex (like create an XML document from a collection of form elements), that too is more involved. These are the types of functions I envision the tags providing for you as standard actions. If you need to do something non-standard, no problem either. > and it could be reused for any innerHTML replacements by changing the > url in the function call. I don't think button has an innerHTML > property but just to use the example given, you get the idea.... > Probably having a javascript library with updateValue() and other useful > often changed properties would do the trick. That is a good idea! I'll think I'll steal that for some of my standard actions :) > If anyone ever takes this on I'd appreciate it if you could keep me in > the loop on development of it. I would help as well as needed. Maybe > the dojo team has something like this already in mind? One note: you would in fact be able to do what you are doing here with my tags as well, the only difference is that you wouldn't have to write that code, either the function or the event handler. You could instead specify it in an XML config file. > The quick sample I put together doesn't use dojo so I haven't tested the > specific code but I have tested the idea with a test script and it does > work. > > Hope the above makes sense. Does anyone see negatives to using the > above? It seems to take care of the code duplication concerns. The url > concern can be handled by making it a variable passed from the server > side I would guess from a form or other similar mechanism would do the > trick there. I don't have any concerns with it per se, but I do think there is more that can be done, and I still think the tags are the best way to present it. Hey, if you'd like to be involved with my efforts, I could certainly use the help in creating the transmission and reception handlers (a new concept in my approach, I can bring you up to speed privately if you are interested). This way you could even do one version that uses Dojo if you want! Frank > I was interested in the conversation, hope this adds some value. > > Regards...djsuarez > > -----Original Message----- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 19, 2005 10:49 PM > To: Struts Users Mailing List > Subject: Re: AJAX: Whoa, Nellie! > > Martin Cooper wrote: > >>My "Huh?" comment was in reference you your statement that the > > approach I > >>was describing "doesn't really help people with existing apps", which > > I take > >>issue with. If you put the JavaScript methods in separate file, it has > > the > >>exact same impact on the JSP pages as your approach does, but without >>needing the custom attributes. You say 'ajaxRef="button1"' and I say >>'onclick="doButton1()"'. > > > Ok, I may have misunderstood that. > > Moving on though... > > > "If you put the JavaScript methods in separate file, it has the > > exact same impact on the JSP pages as your approach does" > > I do not belive this is true, and here's why... as far as the event > handlers go, I agree, the impact is virtually identical... But in terms > of what the event handler calls there is I think a big difference. > Going back to your original example, you state: > > Elsewhere in the JSP page, or maybe somewhere else: > function doButton1() { > dojo.io.bind({ > url: > "http://www.omnytex.com?buttonValue=button1&textValue=text1";, > load: function(type, data) { > document.getElementById("resultLayer").innerHTML = data; }, > mimetype: "text/plain" > }); > } > > Now, that looks like more work to me because, if nothing else, I'm > writing the return handler myself. And if I had to write 20 of these > functions for a single page, ugh! You mentioned DynaActionForms saving > a lot of tedious coding... this is about as tedious as it gets :) > > If you want to argue that moving these functions out to another file > that you include makes the situation better, I'd say only marginally > better because the benefit of separating the code is offset somewhat by > the fact that now there are two files to maintain. Then again, you > could also argue that THAT is better because you can have coders > handling the JS while you have page authors handling just the markup :) > (beat you to the punch on that one!) > > ** > > You know, it just dawned on me... in all of this, recall that my > proposal allowed for you to call whatever JS function you want rather > than have the code generated for you... there is absolutely nothing to > stop you from calling a function that uses Dojo! This gives you, I > think, the best of both worlds: you get to use Dojo, but you can still > do so in a declative way... although, you'd take on the responsibility > of importing the necassery JS code and implementing the send and receive > > handlers, at which point there probably isn't a whole lot to be gained > by the config file anyway, in fact it would probably be > counterproductive... but the point is you *can* do this. > > ** > > You know, when all is said and done, we simply have a difference of > opinion in all this. I'd bet neither of us really wants to debate this > for the next week :) I think we're probably at that point where we > aren't going to convince each other of anything but some relatively > small points at best. > > I don't deny that Dojo looks cool, and if you are happily using it I am > genuinely happy about it! If you want to tell people how great it is, > that is fine with me too (although I would hope you recognize your > position gives your opinions weight and would be a little careful about > proclaiming anything to be the endorsed answer). > > I am going to go off and implement my idea because if nothing else I > have seen a decent amount of interest amidst all this debate. The > simple fact that the whole concept was reopened by someone else (I had > nothing to do with it, I was actually completely off this whole idea > after the initial RFC thread died down) should indicate it isn't just me > > that thinks it has merit. > > In the end, choice is good. Like all FOSS projects, if when it's done > people find it useful and want to use it, that will make me rather > happy. If they discover Dojo and think it's the cat's meow, that is > sweet too. If they go off in a completely different direction, things > are working as they are supposed to because a choice was made between a > number of options :) > > Frank > > > > > > -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
