I'm not so familiar with Ajax but I keep hearing Json mentioned as some kind of competing option. Is there a rule for when to use one versus the other?
I'd like to process Javascript events in my app and update the front-end dynamically from the app but I'm not sure whether I need to use Ajax or Json for this.
Ajax and JSON are very different things.
From Ajax (programming):
Ajax, sometimes written as AJAX
(shorthand for asynchronous JavaScript
and XML), is a group of interrelated
web development techniques used on the
client-side to create interactive web
applications or rich Internet
applications. With Ajax, web
applications can retrieve data from
the server asynchronously in the
background without interfering with
the display and behavior of the
existing page. The use of Ajax has led
to an increase in interactive
animation on web pages and
better quality of Web services thanks
to the asynchronous mode. Data is
retrieved using the XMLHttpRequest
object. Despite the name, the use of
JavaScript and XML is not actually
required, nor do the requests need to
be asynchronous.
From Introducing JSON:
JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.
Here's some JSON:
{ "taco" : "awesome", "burrito": "less awesome", "fishTaco": "1000" }
Looks pretty much like an array in this case.
And you can use AJAX to get the JSON. I use it to return table data often. You've probably already used JSON-like data in your javascript but didn't realize it.
I prefer to request JSON data rather than XML or HTML. I find it easier to deal with than XML, and more flexible than HTML.
JSON is not a competing technology to AJAX it's just a data format.
Where you might hear competition is between XML and JSON, JSON having the advantage of being typically lighter and in native javascript already, XML having the advantage of portability and toolsets.
Introducing JSON
As some have stated, these are two different things entirely. AJAX is a method of using JavaScript to initiate HTTP requests to fetch data. That data can be in any sort of format, but most commonly XML, HTML, and yes, JSON.
So, as already mentioned, JSON is a data format much like XML or CSV, just with a different set of formatting rules.
Json is nothing more (and nothing less) than a format of the data you transfer with the Ajax-way of talking to the server.
Some transfer the data in the form of xml, other just plain text, others use Json.
More info about JSON on Wikipedia: http://en.wikipedia.org/wiki/Json
Ajax and JSON aren't the same thing. Ajax is a technique combining, among other things, lightweight asynchronous requests and typically some DOM manipulation, in order to create richer user interfaces in web applications.
The "X" in Ajax is often taken to mean "XML", and many sites using Ajax use XML as the format of the data returned by the server in response to such requests.
JSON (http://json.org) is a lightweight data interchange format based on Javascript's object notation. As such, it's easy to parse in Javascript. It's also a lot less verbose and repetitive than XML.
I think you may be talking about AJAX vs JSONP
http://en.wikipedia.org/wiki/Json#JSONP
If that's the case, the one benefit of using JSONP, is that you can get around the cross-site sandboxing (although, possibly introducing new security risks)
AJAX is used for get data from server, whereas JSON is just a data format which can used to send data to the server.
I thought I would provide this comparison from my class lecture
AJAX (Asynchronous JavaScript + XML) incorporates several technologies:
Standards-based presentation using XHTML and CSS;
Dynamic display and interaction using the Document Object Model (DOM);
Data interchange and manipulation using XML and XSLT;
Asynchronous data retrieval using XMLHttpRequest;
JavaScript binding everything together.
JSON, short for JavaScript Object Notation is a lightweight data interchange format. Its main application is in AJAX web application programming, where it serves as an alternative to the use of the XML format for data exchange between client and server.
The above answers are correct, but If you are new to using web technologies, all you need to know is simply
that Ajax is a subset of JavaScript.
It is a technology, a means for you to send only portion of the web page data back to the server to get processed
and get the response back while the user is interacting with other parts of the page. This way, the
Interaction with the page is consistent and seemless from the user stand point. Now, JSON on the other hand is
the how you can format the data (similar to XML) that you are sending back to the server, and getting back.
and it's used primarily with Ajax. It was developed and used mainly
because it is lightweight and human readable, which makes it more efficient and user friendly.
Hope that helps a bit.
Related
I'm planning on experimenting a bit with the HTML5 History API on my website to asynchronously render new content and save states for the browsers that support it. Obviously this means making a lot of AJAX requests to the server, and I've hit a snag in terms of design approach. I've some areas on the site that already render content asynchronously in small ways, and in those places I've just been rolling my own solutions to generate the new HTML on the client side.
However, what I'm trying to do now will require a bit more of a robust solution, and I'd like to do it in a way that takes advantage of the MVC flow rather than relying on a javascript templating engine or my own whacky javascript to handle the raw data returned by my controllers. Since this feature will only be relevant to certain HTML5 capable browsers, I'd rather not introduce a lot of extra bloat on the client side for something a lot of people may not even see.
Essentially, what I'm wondering is: is there a way in Cake to take advantage of the presentation logic that's already in my view files to selectively generate and return just the new, ready-to-go HTML that I need instead of reinventing the wheel to do it on the client side from raw data returned by the controller?
I don't really get your problem but i sounds like you want to cache the view which is in fact rendered by a view class but send back to the browser through the controller by using the CakeResponse object.
Caching: http://book.cakephp.org/2.0/en/core-libraries/caching.html
Response: http://book.cakephp.org/2.0/en/controllers/request-response.html#cakeresponse
Is anything that uses JavaScript and asynchronous communication of XML data considered Ajax?
Most people who deal with AJAX would consider any usage of XMLHttpRequest to be AJAX.
This doesn't mean that the request need be async either.
These days, JSON replaces XML for communications.
From wikipedia:
With Ajax, web applications can send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display and behavior of the existing page. Data is usually retrieved using the XMLHttpRequest object. Despite the name, the use of XML is not needed (JSON is often used instead), and the requests need not be asynchronous.
AJAX seems to encompass any application which retrieves data using the XMLHttpRequest object. Despite it's name you don't need to use XML and I'd wager most AJAX apps these days are using JSON instead. Also they don't necessarily make asynchronous requests. We probably need a new buzzword at this point. Maybe websockets will take off!
The term AJAX and its abbreviation is a misnomer. It has nothing to do with XML. It typically refers to the XMLHttpRequest function. The name of this function again is a misnomer because you could use it to get or send JSON data, plain text, or even binary data now.
AsyncHttpRequest would have been a more appropriate term for the function, and AJAH (Asynchronous JavaScript and HTML) instead of AJAX. On a side note, although XMLHttpRequest allows synchronous requests too, they'd probably be better off getting rid of it altogether.
Typically AJAX applications make good use of asynchronous calls and avoid page refreshes as much as possible. Gmail is a good example. Facebook, on a modern browser, also uses AJAX. Clicking on different links like "News Feed", "Events", etc. doesn't cause a page reload although the path in the address bar changes. Github does the same on modern browsers.
I have never used Ajax with JSON. Are there any good resources to look upon?
Think of Ajax as a way to send and receive textual content with the server. The format of the messages you send back and forth is up to you. You could use JSON, XML, YAML, CSV, or whatever else you want.
If you separate these two concerns your problem should be a lot easier to approach.
Figure out how to make an Ajax call to your server
Figure out how to parse and serialize JSON
If you use a JavaScript framework, like jQuery or Prototype, both of these things will be handled for you pretty seamlessly with their Ajax APIs.
http://api.jquery.com/jQuery.ajax/
http://www.prototypejs.org/api/ajax/request
I have no idea about AJAX programming features. I just know that it is Asynchronous Javascript and XML.
Please help me in knowing about this language.
I have gone through many AJAX tutorials. But none of the programs are running. Why I don't know.
Do we save the file with .HTML extension?
Read:
AJAX Tutorial by W3Schools.
AJAX Programming by Google Code University
To start coding you can get the Ajax Control Toolkit by Microsoft. You should read Ajax Control Toolkit Tutorials to get a grasp of it.
You can use the free Microsoft Visual Web Developer 2010 Express Edition as your IDE.
Aside from the correct responses that the others gave you, judging from your question I think you first need to learn about client-side and server-side code.
Do we save the file with .HTML extension?
Yes and no. You will have an HTML frontend, that for instance contains a button. This will be interpreted from the client's (=user) browser. In fact it may be rendered differently depending on the browser/OS/etc.
Now, you attach some Javascript code to this button. This also runs on the client's browser, and creates a XMLHttpRequest object, either directly or through the use of a library (JQuery & Co.). Note that a library is not necessary to do an AJAX request. It will make your life easier if you do a lot of AJAX calls, but it is not essential.
And here's where the magic happens: the XMLHttpRequest object will call asynchronously (i.e.: without reloading the page) a server-side page. This may be a PHP, ASP, Perl etc etc file that does something on the server, for instance queries a database. This part of the operation is absolutely independent from the client. The user can close the browser before the server-side code finishes to load and the server will not know about it.
Once the server-side code has finished executing it returns to the client with some response data (e.g. a piece of XML, JSON, HTML or whatever you like). Finally the client executes (or not) some other Javascript code in response to this, for example to write on the screen, again with no reloading of the page, something based on what the server has returned.
Maybe I can help you understand AJAX by clarifying the concepts a bit.
Please help me in knowing about this language.
AJAX is not a language, it is a way of using existing techniques to improve the user experience of a web site. The language is Javascript in the browser but you can use any server side technique that you feel comfortable with (ASP.NET, Java, PHP, Ruby etc.)
Do we save the file with .HTML extension?
Well, that is not really the point. What you have to grasp here is that there is a server and a browser that interact with each other. Yes, you can use static HTML files for your pages (and save them as .html files), but you'll need a server to respond to the requests of the browser. This may be why your sample code is not working; you need to set up a server that works with your pages.
The whole idea behind AJAX is to improve the user experience by not reloading the entire page when a user interacts with it. You request the data you need and update the page by using Javascript to update the HTML. This is called an out-of-band or asynchronous request.
I just know that it is Asynchronous Javascript and XML.
That is what the acronym stands for but it doesn't quite cover what the technique is for, nor is it accurate any more. In the beginning XML was used to transfer data from the server to the client. People found that XML is not really that easy to work with in Javascript so now it's more common to use JSON. JSON is a snippet of javascript that can be evaluated in the browser. The snippet creates javascript object(s) that represent the data.
If you use a Javascript library, like others have suggested here, you won't have to worry about many of the details though.
Before you get into AJAX you should make sure that you understand:
HTML and CSS
Javascript
how to modify HTML with Javascript
how a browser requests information from a server
how to handle requests on the server
If you are not comfortable with all of these concepts, stick with 'regular' web pages and try to improve your knowledge step by step.
Once you get the basic knowledge from W3school, I suggest you use a framework. Usually developers do not use XMLHttpRequest at all. Instead, javascript frameworks like ExtJS, jQuery and other frameworks make your work simple. I suggest you learn bit of javascript as well. check out jQuery.
Just to add that AJAX is rarely used in its pure form with XMLHttpRequest. You will often use it as a part of AJAX UI libraries which make your life easier. If you are from the Java world - such an AJAX library is Richfaces.
Instead of worrying about how to do AJAX, use something that allows you to forget about it. Frameworks like NOLOH do AJAX (and Comet) for you automatically without you having to do a thing. Just concentrate on your application, and business logic and it does the rest.
Really, everything is done via AJAX if available, automatically. No work on your part. If you're don't want to spend much time researching it, check out this short video that was demonstrated at Confoo PHP Conference this past March http://www.youtube.com/phpframework#p/u/11/cdD9hSuq7aw.
For all those worried about, well, if it's all AJAX, what about search engines? No need to worry, http://dev.noloh.com/#/articles/Search-Engine-Friendly/.
So instead of having to worry about all these different technologies, or the client-server relationship, you can sit down, code and have your website/WebApp working in no time.
You can read about NOLOH is this month's cover story of php|architect magazine, http://www.phparch.com/magazine/2010/may/.
Enjoy.
Disclaimer: I'm a co-founder of NOLOH.
It is easy one. Ajax getting data from server side by client side execution. We have to do use XMLHttpRequest to get the result.
I am trying to find the optimal architecture for an ajax-heavy Django application I'm currently building. I'd like to keep a consistent way of doing forms, validation, fetching data, JSON message format but find it exceedingly hard to find a solution that can be used consistently.
Can someone point me in the right direction or share their view on best practice?
I make everything as normal views which display normally in the browser. That includes all the replies to AJAX requests (sub pages).
When I want to make bits of the site more dynamic I then use jQuery to do the AJAX, or in this case AJAH and just load the contents of one of the divs in the sub page into the requesting page.
This technique works really well - it is very easy to debug the sub pages as they are just normal pages, and jQuery makes your life very easy using these as part of an AJA[XH]ed page.
For all the answers to this, I can't believe no one's mentioned django-piston yet. It's mainly promoted for use in building REST APIs, but it can output JSON (which jQuery, among others, can consume) and works just like views in that you can do anything with a request, making it a great option for implementing AJAX interactions (or AJAJ [JSON], AJAH, etc whatever). It also supports form validation.
I can't think of any standard way to insert ajax into a Django application, but you can have a look to this tutorial.
You will also find more details on django's page about Ajax
Two weeks ago I made a write up how I implement sub-templates to use them in "normal" and "ajax" request (for Django it is the same). Maybe it is helpful for you.
+1 to Nick for pages displaying normally in the browser. That seems to be the best starting point.
The problem with the simplest AJAX approaches, such as Nick and vikingosegundo propose, is that you'll have to rely on the innerHTML property in your Javascript. This is the only way to dump the new HTML sent in the JSON. Some would consider this a Bad Thing.
Unfortunately I'm not aware of a standard way to replicate the display of forms using Javascript that matches the Django rendering. My approach (that I'm still working on) is to subclass the Django Form class so it outputs bits of Javascript along with the HTML from as_p() etc. These then replicate the form my manipulating the DOM.
From experience I know that managing an application where you generate the HTML on the server side and just "insert" it into your pages, becomes a nightmare. It is also impossible to test using the Django test framework. If you're using Selenium or a similar tool, it's ok, but you need to wait for the ajax request to go return so you need tons of sleeps in your test script, which may slow down your test suite.
If the purpose of using the Ajax technique is to create a good user interface, I would recommend going all in, like the GMail interface, and doing everything in the browser with JavaScript. I have written several apps like this using nothing but jQuery, state machines for managing UI state and JSON with ReST on the backend. Django, IMHO, is a perfect match for the backend in this case. There are even third party software for generating a ReST-interface to your models, which I've never used myself, but as far as I know they are great at the simple things, but you of course still need to do your own business logic.
With this approach, you do run into the problem of duplicating code in the JS and in your backend, such as form handling, validation, etc. I have been thinking about solving this with generating structured information about the forms and validation logic which I can use in JS. This could be compiled at deploy-time and be loaded as any other JS file.
Also, avoid XML. The browsers are slow at parsing it, it is a pain to generate and a pain to work with in the browser. Use JSON.
Im currently testing:
jQuery & backbone.js client-side
django-piston (intermediate layer)
Will write later my findings on my blog http://blog.sserrano.com