You??™ll find out
later in the chapter that while it is possible to access and interpret the submitted data in
another format pretty easily, should you? Consider if the Ajax application is built to degrade
to work without JavaScript? Do you want a complex back-end that handles data submissions
in one format when JavaScript is on and another when it is off? For ease of migration from
old form-based post-and-wait style to the new Ajax style, it is likely that staying with the
traditional x-www-form-urlencoded format is the way to go. However, for the Ajax
response, we do not give the same advice.
Encoding/Decoding Responses
Traditionally, server-based Web applications respond with fully baked Web pages implemented
with (X)HTML, CSS, JavaScript, and other related technologies. As we have seen, in Ajax
applications, the focus is different; instead of fully rendered pages, we return smaller
amounts of data and then update the pages or the application state more incrementally. This
begs the question: what format should be selected for sending such responses?
From a server-side encoding point of view, depending on the application architecture,
some response data formats may seem more appropriate than others. For example, if the
application traditionally generates XML and then translates it to HTML to be delivered to
the browser, it may now be easier to send the XML directly and have transformations
applied locally in the browser.
Pages:
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193