 |
 |
I agree with Chad and Jason. It's all about having many options because every situation is different. Each will call for one format or another for efficiency, convenience, and the best user experience (among many other considerations). In a current project, I'm using both JSON and HTML AJAX calls. -Shaun On 12/8/11 9:09 AM, Chad Mills wrote: > I used to find myself in the same quandary when writing scripts intended for AJAX interaction. I came around to a solution that works for me, and it is more of a programming style than anything. I basically leave the option open to the requester of the AJAX script to declare an output format. How I start is I form my response in an DOM, I use PHP. I leave a format variable open in the request at the time of returning a response I either dump the XML, convert it to JSON, or run it though XSL stylesheet for HTML. Starting out it took me longer to develop these AJAX utility scripts, but after a couple of them it's second nature to me. It doesn't seem to any longer to develop, the format conversion is cheap, processing wise, and at the end and I leave the ultimate choice to whomever calls the AJAX script so I impose the least amount of restrictions on its use. > > -- > Chad Mills > Digital Library Architect > Ph: 732.932.8573 x123 > Fax: 732.932.1386 > Cell: 732.309.8538 > > Rutgers University Libraries > Scholarly Communication Center > Room 409D, Alexander Library > 169 College Avenue, New Brunswick, NJ 08901 > > http://rucore.libraries.rutgers.edu/ > > ----- Original Message ----- > From: "Esme Cowles"<[log in to unmask]> > To: [log in to unmask] > Sent: Thursday, December 8, 2011 8:57:28 AM > Subject: Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable) > > I've been following this thread very closely, and find myself torn. Doing all the HTML generation server-side seems like the easiest way to have a single set of template code that's shared between JS and non-JS paths, reducing complexity of the overall app, and making graceful degradation easier. On the other hand, doing client-side HTML generation (or direct DOM updating) seems like it offers better performance, greatly reduced bandwidth, and a better fit if you want to create a reusable API. > > I think there is a third way: using the same template code for both client-side and server side rendering. The basic HTML version would retrieve pages rendered server-side, and the enhanced JS version would retrieve JSON and render the UI with the same templates (presumably with modular templates so the JS version would only have to update the areas with updated content, and not the entire page). The only template systems I know of that have both client and server support are XSLT and Mustache. Are there others? Has anybody set up a system like this? > > -Esme > -- > Esme Cowles<[log in to unmask]> > > "The wages of sin is death but so is the salary of virtue, and at least the > evil get to go home early on Fridays." -- Terry Pratchett, Witches Abroad > > On 12/7/2011, at 9:38 PM, Jonathan Rochkind wrote: > >>> Also, I've thought of a good reason myself: performance. If I'm adding >>> an item to a list, it's a better user experience to update the display >>> immediately rather than waiting for the server to send back a 200 OK, >>> and handle the error or timeout case specially. >> >> While in general I tend toward the other the other thing you said, "Does it make sense to replicate the >> server-side functionality on the client?" -- I think what you propose above is legit. >> >> MOST people don't write interfaces like that, even in js. That is, an interface that will update the user interface even before/without receiving _anything_ back from the server. (But, in the best cases, produce and error message and/or 'undo' the user interface action iff the server does later get back with an error/failure message). >> >> So if you're going to do that, then--- it kind of doesn't matter if the server sends back HTML or JSON or anything else, the user interface is updating before/without getting _anything_ from the server. But to the extent the server's response then serves pretty much only as a notification-of-failure or whatever, yeah, JSON is the way to go. >> >> So, yeah, if you're going to go all the way there, that's a pretty cool thing (if you can make sure the failure conditions are handled acceptably), sure, go for it. -- Shaun D. Ellis Digital Library Interface Developer Firestone Library, Princeton University voice: 609.258.1698 | [log in to unmask]