On Tue, April 19, 2005 2:33 pm, Vic Cekvenich (netsql) said: > Frank W. Zammetti wrote: >> Not if I complete my project! ;) >> > > > I hope you do! > See if you can put some version on struts.sf.net, this is how some > committers got in.
That's my plan at the moment. There frankly isn't a ton left to do to get it to an initial release, maybe 20 hours or so of solid wokr, so if I can find some time this week or next I should be able to bang it out, then the fun of testing and blowing it up begins :) > I am no JavaScript guru, but something similar to XUL and new W3 XForms, > were it's even possible to just send XML-RPC style XML to the server, > beyond the XMLRequest or inside it. And then have a .js library that > .... generates HTML. My only concern with those ideas is the requirement of using XML. To be honest, where I've used AJAX-type techniques in the past, I've only used XML one time. I plan on allowing for both with what I'm doing, but looking down the road, I'm not really convinced that XML being sent and received all the time is the way to go... XML has never seemed to me a good way to go for things that are essentially transactional (where transactional here really just means potentially numerous and rapid-fire, i.e., UI events). The transport time is greater, although that concern isn't as great as it used to be, and there is also the added delay of parsing and creating it. Then again, I wouldn't want to create my own protocol for something like that, so it's a tough call either way. > I got this from MC (not CM), but it's a strech I think. > > http://nwidgets.org > > http://dojotoolkit.org The Dojo things looks cool, but at least upon a quick read through it, didn't strike me as much more than a wrapper (albeit a very nice one) around XMLHttpRequest, with the added capability of using other "transports", whatever that means in this case. That isn't meant to belittle it in any way, it does look nice for what it is, but my initial impression is that it's just a piece of the puzzle, not a full-fledged solution. I'll check it out in more detail though, I could certainly have missed something as quick as I went through it. > The more "generating of html" you do in browser, the more scalability > you have on server and the faster it appears to user. I agree, however, the caveat is that if you do too much you'll have just the opposite effect. Case in point... The app I've been referring to today from a couple of years back had on one screen the ability to page through data and do real-time sorting. This was done by making calls to the server to get chunks of data which was returned something along these lines: <html><head><script> a = new Array(); a[0][0] = "Frank"; a[0][1] = "Zammetti"; a[1][0] = "Cindy"; a[1][1] = "Crawford"; </script></head> <body onLoad="window.top.fraAPI.doLoad()";></body> </html> So, when this is returned (to a hidden frame), it fires the doLoad() function in another hidden frame (named fraAPI), which would take the data from the array and generate the HTML. It's nice because only data is ever returned from the server (plus the small amount of scripting and page "infrastructure"). The problem arose, initially, because we were allowing for something like 300 records max at a time. Such a request was taking like 5 seconds on a P3 550. As it turns out, the response from the server was sub-second (VERY low, better than anything we see even today in current apps doing everything on the server), the rest was the actual rendering. We simply reduced the number of records you could look at at one time, but you could see a big different if you went to a more powerful PC. This isn't ideal either, so you have to deal with the tradeoffs well to make this approach work well. Frank > > .V > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
