AJAX without XML

V

VK

Anyone knows a reputable source of info: who did first say AJAX ?

I tried to google out, but it seems like Homer's writing: "Seven cities
acclaimed the Homer's homeland" :)

So who did coine this term?
 
M

Michel

Certainly...

However I don't like the idea of sending javascript as a response to the
client and then eval it. Sounds like a maintentance nightmare. However
you could pass the response as a textual message and parse and process
it at the client. The textual message needen't be xml/soap webservice
whatever but could be your own designed optimized protocol since there
is a bit of overhead in xml/soap and the like and if you eg is providing
financial price updates a couple of times/sec using ajax the overhead
might come prohibitive.

/M
 
D

dave.c.johnson

Using JavaScript as the data transport encoding is very popular and can
be extremely handy if your application is closed (ie you are not going
to provide the data to someone else). Furthermore, if the data you are
returning a single JavaScript object that needs to be used _in
JavaScript_ then by all means use JSON - it is much nicer than parsing
the XML DOM to look at values etc.

But if you are returning an array of data that needs to get into the
web page DOM (and will maybe need sorting / filtering on the client)
then use XML since XSL can be much easier to use for some people and it
can be re-used on both the client and server.

If speed is important you should also take into accound the browser
demographics when considering using JSON [1]. XML + XSL is far faster
than JSON in IE and vice-versa in Mozilla browsers. But depending on
your demographics then XML will likely scale better.

dave

[1] http://blogs.ebusiness-apps.com/dave/?p=45
 
T

Thomas 'PointedEars' Lahn

Using JavaScript as the data transport encoding [...]

I beg your pardon? The transport/transfer _encoding_ never was JavaScript,
but was and is US-ASCII, ISO-8859-XX or UTF-16, for example. Perhaps you
meant "data _format_" which is a completely different thing.
But if you are returning an array of data that needs to get into the
web page DOM (and will maybe need sorting / filtering on the client)
then use XML since XSL can be much easier to use for some people and it
can be re-used on both the client and server.

What are you talking about? An array is a data structure. If that is
returned, JSON is definitely the best format as the language it is built
on has built-in array support. Perhaps you meant returning a DOM subtree
with several child elements where XML would be more appropriate.


PointedEars
 
D

Dag Sunde

Thomas 'PointedEars' Lahn said:
Using JavaScript as the data transport encoding [...]

I beg your pardon? The transport/transfer _encoding_ never was
JavaScript,
but was and is US-ASCII, ISO-8859-XX or UTF-16, for example. Perhaps you
meant "data _format_" which is a completely different thing.
But if you are returning an array of data that needs to get into the
web page DOM (and will maybe need sorting / filtering on the client)
then use XML since XSL can be much easier to use for some people and it
can be re-used on both the client and server.

What are you talking about? An array is a data structure. If that is
returned, JSON is definitely the best format as the language it is built
on has built-in array support. Perhaps you meant returning a DOM subtree
with several child elements where XML would be more appropriate.

In some cases, it can be preferable to just return a string with
semicolon separated values, and .split() it on arrival. If nothing
else, it is compact, and does not depend on any libraries being present.
 
T

Thomas 'PointedEars' Lahn

Dag said:
Thomas 'PointedEars' Lahn said:
Using JavaScript as the data transport encoding [...]
I beg your pardon? The transport/transfer _encoding_ never was
JavaScript, but was and is US-ASCII, ISO-8859-XX or UTF-16, for
example. Perhaps you meant "data _format_" which is a completely
different thing.
But if you are returning an array of data that needs to get into the
web page DOM (and will maybe need sorting / filtering on the client)
then use XML since XSL can be much easier to use for some people and it
can be re-used on both the client and server.
What are you talking about? An array is a data structure. If that is
returned, JSON is definitely the best format as the language it is built
on has built-in array support. Perhaps you meant returning a DOM subtree
with several child elements where XML would be more appropriate.

In some cases, it can be preferable to just return a string with
semicolon separated values, and .split() it on arrival. If nothing
else, it is compact, and does not depend on any libraries being present.

I can agree to that, in fact I did not debate it in the first place. What
I commented on were the terms "data transport encoding" and "array" being
wrongly used. I may be splitting hairs but I do think it is vital for a
developer, in fact for anyone in IT, to know the difference.


Regards,
PointedEars
 
D

dave johnson

I agree it is important for you to know the difference PointedEars. I do
admit that encoding was not necessarily the best word but it's really
just semantics. If you want to get technical, <a
href="http://www.dictionary.com">dictionary.com</a> says that <a
href="http://dictionary.reference.com/search?q=encoding">encoding</a> is
simply "To format (electronic data) according to a standard format"
(notice the use of the word format in there). I think that you are
assuming I was refering to is the <a
href="http://en.wikipedia.org/wiki/Character_encoding">_character
encoding_</a>.

Secondly, my reference to an _array_ was used as a general term. An
array <i>can</i> be a data structure but you really should understand
what an "array of data" is in the context of XML and JSON - can you
imagine what this means in C++ or Java? You can consider an array as a
group of objects/values formatted using either JSON or XML - again ask
dictionary.com what an array is. If someone says you have an array in
JSON then it might look something like this:
{'myArray': [
{'index1': 'value1'},
{'index2': 'value2'},
...]}
while an array in XML might look like this:
&lt;r&gt;
&lt;e a="index1" b="value1" /&gt;
&lt;e a="index2" b="value2" /&gt;
...
&lt;/r&gt;
Essentially both of those are a one dimensional list of objects.

Now that we all understand arrays and encoding we can get on with the
conversation. All that I am saying is that if you have a large _array_
of data (ie a list of, say, customer objects). If you use JSON to
transfer this data from the server to the client then you first have to
call eval(myJSONString) (which is slow) and then loop through the
resulting JavaScript array and build a string or DOM tree of the data
(which can also be slow) that is ready to be put into the web page -
this is not even considering the even slower cases where the data has to
be filtered or sorted. Alternatively, you can return the customer
records to the client as XML in which case all that has to be done is
the XML has to be transformed using an XSLT stylesheet into an HTML
string and then inserted into the document using the innerHTML property.
The XSLT can be used on the client or server (less logic written in
JavaScript :) ) and XSLT has great (fast) support for sorting and
filtering of data.

The important factors here are the length of the array of data you are
dealing with and the target browser. Given that XSLT is quite slow in
Firefox, the question becomes "is the performance hit on Firefox small
enough that the performance in Internet Explorer compensates given the
end user browser demographics".

The one time that JSON is really good is if you are returning a single
record like:
{'car':{
'color':'red',
'make':'Smart',
...}}
and you are going to either insert this into the page DOM or, even
better, you are going to check the color using JavaScript and then do
something else - nothing to do with the UI - based on the color of the
car. In these cases, JSON can be VERY useful.

happy AJAXing.
 
K

Kevin Darling

I wrote a small piece about AJAX without XML.

http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=AJAXWithoutXML

Is anybody else doing it? Please share your thoughts...

At least in IE 5+, you can do the same _without_ using either
XMLHttpRequest or the eval function.

Simply use a normal <script type="text/javascript" id="DATA" src= etc>
element, and then change the DATA.src value dynamically. (If you wish
the same file but a new version, do the usual src=name + "?ver=" + new
Date() trick.) IE will load (from cache or server) the new script
and evaluate it for you.

You can use this to load array data, functions, inline code, or
whatever. The same can be done with IE's <xml> element, for XML data.

I'd be curious to know if all other browsers support this dynamic
<script> src attribute change ability.

Cheers, Kevin
 
K

Kevin Darling

Kevin said:
At least in IE 5+, you can do the same _without_ using either
XMLHttpRequest or the eval function.

Simply use a normal <script type="text/javascript" id="DATA" src= etc>
element, and then change the DATA.src value dynamically. [...]

I might add that you can also use this to preload multiple sets of data
or functions with the same internal names, and dynamically choose
between them. For example:

<script type="text/xml" src="version1.js"></script>
<script type="text/xml" src="version2.js"></script>
<script type="text/javascript" id="TEST"></script>

The scripts marked "text/xml" will not execute. Then you can do
TEST.src = "version1.js" or "version2.js" in your page, and the TEST
script contents will dynamically change to the desired script from
cache.

We have thousands of field techs who are off-line most of the time, and
we use a lot of caching techniques to provide the capablity of off-line
validation etc, on a daily per-job-type basis.

Cheers, Kevin
 
R

Randy Webb

Kevin Darling said the following on 11/27/2005 2:19 PM:
At least in IE 5+, you can do the same _without_ using either
XMLHttpRequest or the eval function.

And it is *much* more widely supported than the "AJAX" is. As for what
"AJAX" is, it is a common cleaning product in the USA.
Simply use a normal <script type="text/javascript" id="DATA" src= etc>
element, and then change the DATA.src value dynamically. (If you wish
the same file but a new version, do the usual src=name + "?ver=" + new
Date() trick.) IE will load (from cache or server) the new script
and evaluate it for you.

You can use this to load array data, functions, inline code, or
whatever. The same can be done with IE's <xml> element, for XML data.

I'd be curious to know if all other browsers support this dynamic
<script> src attribute change ability.

No, IE is the only one that supports changing the .src attribute. And
even then, it is the PC IE, IE on the MAC doesn't support changing the
..src attribute.
There is a thread in comp.lang.javascript that covers how to dynamically
load a .js file on the fly and which browsers support which methods.

The most widely supported method is to use createElement to create a new
script element and appendChild to append it to the document.

function loadJSFile(fileURL){
var JSFileToLoad = document.createElement('script');
JSFileToLoad.type = "text/javascript";
JSFileToLoad.src = fileURL;
document.getElementsByTagName('head')[0].appendChild(JSFileToLoad);
}

and then call it like this:

loadJSFile('someJSFile.js');

That is without the necessary feature detection since not all browsers
support gEBTN and appendChild

You could go one step further and append the script to a DIV tag and at
the beginning of the function remove the contents of the DIV tag so that
you discard any/all old JS files.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top