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.
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"
});
}
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 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.
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?
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 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
