Re: HTML_AJAX next steps

Luca, I've not thoroughly reviewed your code, or Joshua's, so I apologize if I miss the mark in any of these comments. Feel free to correct me. I maintain the point I've made previously: Ajax is still stabilizing at the toolkit level, and the best approach would be to agree on a unified API, and then make the rest driver-based. I see three areas where ajax toolkit approaches can be different: 1) How to encode the asynchronous request and response. All of these are valid, with advantages and disadvantages: - Send generic xml, receive generic xml - Send generic xml, receive xhtml for element substitution - Send json, receive xhtml for element substitution - Send json, receive json You and Joshua use different approaches here. 2) How to attach to the HTML, and which events to catch. You use inline Javascript, hand coded, which presents the best responsiveness, but is code-verbose. Joshua seems to be going along a similar path, generating the inline Javascript. Less verbose but still polutes the final markup. A third approach, neither of you use, uses Behaviours: http://www.ripcord.co.nz/behaviour/ which have the advantage of not poluting the markup with javascript code, but losing a bit on responsiveness. 3) How to deal with the fact that requests are asynchronous, whether to place requests in request queues, how to deal with errors (i.e. scrap the rest of the queue, report and continue, go full asynchronous,..). Neither you nor Joshua deal with this problem. Most of the toolkits out there fail here too. In any of these areas, there is no common practice. Advantages and disadvantages for each approach abound, and it is not clear which is the best (or if there is a best generic approach). You can go around discussing point by point your respective approaches, and in the end only reach one conclusion: There is no widely approved model for Ajax yet. I suggest you talk offlist, try to design a top level API that can accomodate as well as possible different backends for the fluctuating Ajax architectures, and then include both your approaches in a common package. It'd be a winner toolkit for sure. Hope I've helped. Cheers, -- Sérgio Carvalho Luca Mariano wrote: > Hi Joushua, > I'm a little unsure about the need to Objectize the javascript side... > and the whole html_ajax2 seems to me more difficult to use that the > previous code, and a bit more cumbersome. > Even when usign the auto_server features adding a single remote > methods involves a great amount of code writing, both on the server > side & on the client. > Moreover, I modified my test page (divide two numbers) using the new > implementation; on my notebook the whole cycle request-reponse (async > mode) requires about 50 msecs; my previous implementation was only 5 > msecs. > I suspect this "slowness" due to the object prototype into JS, and > the JSON encoding-decoding at every request; usually we don't need a > JSON encoding of the data we send to the server, that's true? > On the other hand, it seems that html_ajax2 is more well accepted from > the community; if so I'll be ready to delete my proposal for > html_ajax, so you can propose the new implementation - but you must be > the first mantainer for this because it's your own stuff! > > Regards, > Luca >