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]
