* Thomas Fuchs <thomas@fesch.at> [2005-09-22
02:55]:> Am 22.09.2005 um 03:40 schrieb Alan Gutierrez:
> > My Java servlets can generate both JavaScript objects, like
> > JSON, and XML. I can generate both pretty easily.
> >
> > What''s best practice for AJAX responses? Return scripts to
be
> > evaled by the Ajax control, or return XML documents and iterate
> > them using XML DOM?
> >
> > Thanks.
> For most types of web apps, I''d recommend the following approach:
> 1. If it''s trivial, just return chunks of HTML and update/insert
the
> DOM with it Ajax.Updater in Prototype makes that very easy
> 2. If you need to update several elements at once, generate
> JavaScript on the Server and let the browser eval that
What about:
3. If you are XML happy, return XML and use XPath and DOM to
navigate the document.
That you''ve not suggested it seems to indicate that the eval is
solving a lot of problems. I''ll focus on the two choices above
then.
One of the server side resources I''m developing is an XML
transform that turns...
<ht:div>
<ht:input id="My.Input.1" name="MyInput"
value="Hello!"/>
</ht:div>
Into:
var html = '''' +
''<div>'' +
''<input id="My.Input.1" name="MyInput"
value="Hello!">'' +
''</div>'' +
''''
I''m thinking about how to expand this into a server side builder
generator, so I could have a method like.
var html = Tagger.createCloudChooser(listOfTags)
The magic in the createForm method is generated by transforming
xhtml with elements templating namespace. The result would be a
JavaScript method that takes JSON and emits HTML. You''d be able
specify your doucment using xhtml, and generated it on the
client side using JSON + XSLT generated JavaScript.
(By the way, I''m using XSLT 2.0 as my server side language.)
I''ve created an XML to JSON transform also. So I''ve got
the
foundations for further development of both 1) and 2).
> This has some advantages:
> - All "view" code is done on the server. This eases development
> and you have everything in one place
Right. I guess turning the results into JSON on the server makes
it easier on the browser. The JavaScript parser is primed and
ready to go.
The XML parser is also. I''d imagined that it would be more
efficent to simply create XML and then paste the DOM into the
document, but now I''m recalling that their is an importNode step
in Mozilla, and that IE has two different DOMs, one of HTML and
one for XML (and I mean two totally different imps, not just
ifaces.) IE required that XML be serialized, then inserted.
> - You''re not tying the app completely to AJAX, because you can
> reuse the view code for a non-AJAX version (if done right)
This I considered too. That I could generate JSON and put it in
hidden divs. My application, an Atom feed tagger, will have,
say, 50 articles on a page. The data structures for manipulating
those articles (e.g. tag clouds with frequency data) could be
JSON as text in a hidden div.
The JSON text in the hidden div is parsed when the article is
activated, and when the focus moves to the JavaScript objects
are discarded, replaced with a parse of the next div.
--- in css ---
.json-data { display: none; }
--- in html ---
<div class="json-data" id="Article.Tags.23">
function () {
return {
commonTags: [
{ tag: "uptown", frequency: 1342 },
{ tag: "gardendistrct", frequency: 1087 },
{ tag: "photography", frequency: 231 },
{ tag: "trees", frequency: 34 }
],
articleTaggerTags: [
{ tag: "mid-city", frequency: 2344 },
{ tag: "housing", frequency: 1811 },
{ tag: "uptown", frequency: 1342 },
{ tag: "gardendistrct", frequency: 1087 },
{ tag: "photography", frequency: 231 },
{ tag: "trees", frequency: 34 },
]
}
}
</div>
--- in javascript ---
var articleData = $(''Article.Tags.'' + articleNumber);
var tagCloudGenerator = eval(articleData.innerText);
var tagClouds = tagCloudGenerator();
> - It''s IMHO the least complicated approach
I really like your work. Thanks for this library.
> Here''s an interesing article on this:
>
http://blogs.codehaus.org/people/tirsen/archives/001154_designs_for_remote_calls_in_ajax.html
> Some applications that are very "form intensive" might however
> benefit from only sending the "pure data" across, in that case I
> would pick something that is easily parsed by JavaScript, like
> JSON.
I feel the best way to send data is to turn it into URL encoded
form data and post, or get with a query string. The Prototype
library has serialize methods, and most server side web
frameworks handle this stuff well.
It is reassuring to see simple GETs and POSTs in
script.aculo.us, and not a lot of complicated posting of XML
documents.
> Also, if you have working functions that already generate
> JavaScript (or JSON), use them of course. :)
Thanks for the feedback. It really helps.
--
Alan Gutierrez - alan@engrm.com
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml