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"<[email protected]>
To: [email protected]
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<[email protected]>
"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 | [email protected]
