Mario Ruggier wrote: > On Jul 5, 2005, at 5:12 PM, Ian Bicking wrote: > >> Mario Ruggier wrote: >> >>> Hi, >>> i have just been playing with the recipe: >>> http://quixote.ca/qx/XmlHttpUsingJsolait >>> And it works really nicely... >>> I would need something like this to load rather large chunks of >>> xhtml, that are only made visible when a user asks for them, thus for >>> many page loads they will never be seen. I can see how to send >>> generic python objects... however, to send such data and then >>> "render" this data using js on the client will be rather painful. >>> Besides, the rendering code is already done, in python on the server. >>> Does anyone know if it is possible to either send an xhtml dom >>> object, to be spliced into the page? >> >> >> You can just send the HTML and innerHTML will do what you want, like: >> >> containerElement.innerHTML = remoteResponse; > > > Thanks, Ian, for the reply... > > I was under the impression that innerHTML was non-standard? IE only... It isn't standard, but it is implemented in all the browsers reliably, better than the actual standards, actually. At least that's the impression I've gotten from the Ruby on Rails guys who are very pro-innerHTML and anti-DOM-construction based on reliability. I also understand innerHTML is faster. The only issue, I think, is that in strict XHTML mode browsers might not like it. But maybe I'm misremembering that. >> How you get remoteResponse depends on the transport (e.g., if JSON >> then you get some object back). You could also write the Javascript >> on the server, and just eval() whatever the server responds with. > > > Thanks for the mention of JSON... http://json-rpc.org/ > Was not aware of it. Do you suggest this over xml-rpc? I believe it is significantly faster than XMLRPC on the client side, but I've never tested it myself. And its model is a bit nicer both for Python and Javascript. But often you don't need either -- you can make requests using normal GET/POST variables easily enough, so it's only an issue for the response. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org