I am programming a full ajax web application and did some research in frameworks for SEO and history tracking. I found this one: http://balupton.github.io/jquery-ajaxy/demo/
It looks great but the last update was 4 years ago. Do people still use something like that? Or is there an easier method out?
Yes, AJAX (XHR) is used all the time in web pages. It is still the primary way that JavaScript in a web page makes an in-page request to a server.
There are now also WebSockets, but AJAX (XHR) and WebSockets have different characteristics for largely different purposes (with some overlap).
There is also now an additional interface fetch() for making Ajax calls which makes some things a lot easier than before and this interface is promise-based rather than just using plain callbacks.
The link that you send seems to be for a jQuery plugin called "Ajaxy". AJAX stands for Asynchronous JavaScript and XML, and is a technology supported by native JavaScript (ECMAScript). Yes, people still use Ajax for web applications. If you have ever submitted a form on a modern website, chances are it uses Ajax in some capacity.
Related
I need to make ajax calls to a REST/JSON server from javascript. Both to pull down data to the browser and to push data up. In a web worker.
Because this is in a web worker JQuery cannot be used (details here). And JQuery-hive is a library for managing web workers, not for using JQuery in a web worker (as far as I can tell from the documentation). So JQuery is not an option.
In the limited environment of a web worker, how can I make ajax calls?
Here's something to consider: jQuery is a abstraction tool: it can't do anything which isn't possible with basic JS. it might be easier with pure JS, it might be harder. But it's not magical. It just provides an abstract interface which unifies the different implementations of javascript engines in different browsers.
In this case, jQuery is an abstraction for an XMLHttpRequest. You can find a guide on how to use this on every major javascript website: w3schools.com, MDN, MSDN,... There are also many questions on stack overflow that explain how to do this.
Slightly off-topic, but this is also one of the reasons that I recommend people learning or developing javascript to first learn how to do the things manually, and only switching to a library once they've learned the basics. A library is great for abstraction, but if you haven't learned WHAT is abstracted, you get into trouble once you end up in a situation where you don't have access to the abstraction.
I've been using a couple RESTful APIs for server to server interactions recently and am now thinking about communicating directly with a RESTful API via javascript from within a web browser in my web application.
This would mean using ajax within a web page to talk to my web server using GET, POST, PUT and DELETE requests and the server responding with appropriate http status codes and non-html data (probably json)
Is this generally considered good practice for a web application and why?
It doesn't matter if you are consuming an RPC API or RESTful API from the ajax standpoint, but generally, you can think of a RESTful API as a well-organized, well-namespaced set of remote procedural calls.
Is this generally considered good practice for a web application and
why?
It is useful to do things this way because you don't need to duplicate code in order to have regular CRUD operations across multiple data objects.
Another thing to consider is that if you have a uniform naming convention of API calls that you can write AJAX functions to interact with, you will write and maintain much less code over time in your javascript side of the application, assuming you don't do anything weird in your code.
An example of when / how this would be a good practice would be if you had written a base method designed to automatically determine your AJAX url depending on what you're doing and where you are, and it automatically determines what POST method to use depending on the type of operation... then you literally write one ajax function, and apply it to things rather than write fully separate ajax methods per action item.
I was wondering if it is worth learning javascript first? Does AJAX require Javascript in anyway or is it just similarities in the markup language?
You should absolutely learn javascript. And because AJAX is achieved with javascript, by learning javascript you will also learn AJAX. AJAX is not a different language. It's a pattern that you could use to develop asynchronous web applications using javascript.
Also note that javascript is not a markup language.
First, learn the basics of JavaScript. It's a programming language, not a markup language. You don't need to become an expert immediately, but learn the basics — what it is, the basic structures (functions, control flow statements, variables, objects, etc.), that sort of thing.
Ajax is a technique for retrieving data in a web page without refreshing the full content of the page (or indeed, any of it if you don't want to). You perform Ajax operations (sending a request, interpreting the response) using JavaScript and some other things, such as the XMLHttpRequest object. Ajax isn't a part of JavaScript. They're just used together in the web environment.
(Side note: Although Ajax stands for "Asynchronous JavaScript and XML", the XML part of that is optional; you can do "Ajax" without using XML and in fact, many if not most people do. Ajax lets you send and retrieve all kinds of data, including XML but also including HTML, JSON, plain text, and lots of other stuff.)
Some references that may be useful:
JavaScript:
The Mozilla JavaScript pages
JavaScript: The Definitive Guide by David Flanagan (yes, an old-fashioned paper book)
Crockford's articles on JavaScript (a bit advanced, wait 'till you're ready). Crockford is smart and knowledgeable, but not everyone agrees with all of his conclusions. (I don't.) But it's good to read and understand his points, and make your own decisions. He's mostly right, most of the time.
My own anemic little blog (start with the oldest entries and work forward)
The ECMAScript specification (PDF | handy HTML version)
The DOM
DOM2 Core
DOM2 HTML
DOM3 Core
HTML5 Web Application APIs
(Speaking of which) The HTML5 specification. Parts of it are just codifying what web browsers actually do right now; other parts of it specify new stuff. Mostly you can tell which is which by checking whether the thing in question is part of HTML4. If it is, then likely the HTML5 spec tells you what browsers mostly do today. If it isn't, then it's new and browser support may be perfect, or may be non-existant. :-)
The API docs for the library you choose. There are several good ones: jQuery, Prototype, YUI, Closure, or any of several others. (jQuery is the most widely-used at present.)
Late answer, but here's an analogy if it helps...
Learning JavaScript is like learning to ride a motorcycle.
Learning AJAX is like learning a technique or trick you can do on that motorcycle, like pop a wheelie (though AJAX is more practical than that).
Learning jQuery is like getting some gear to (perhaps) make your motorcycle ride safer or more enjoyable, like a helmet and leather chaps and jacket, or a more comfortable seat and better shocks, or maybe some saddlebags.
So the base of everything is JavaScript. AJAX is just a term to describe something you do in JavaScript, and jQuery is a code library that you may enjoy using when developing in JavaScript, but isn't at all required.
To be more specific, AJAX is a technology that uses javascript for 'part of the work' (it stands for Asyncronous JavaScript and XML), and handling it properly requires knowing at least something about javascript. Also, using a javascript library such as jQuery or Prototype make it much easier to work with AJAX.
JavaScript is a language, AJAX is a technology performed using JavaScript (and usually a web server).
AJAX is 98% Javascript and 2% other. Even the JSON(Javascript Object Notation) you would use for the response data type format, if you choose to, is Javascript. I think this answers your question.
please tell me how to consume webservice (.net) using javascript.
its SOAP.
Thanks
You use AJAX.
In particular the XMLHttpRequest object.
Look at the jQuery ajax API - it makes AJAX easier to use.
I don't think there is a Javascript library that consumes SOAP out of the box. Dojo offers a lot of functionality in that direction, RPC-calls for example, and is probably the one that comes closest.
IBM did some work there that you might want to check out.
This (including Dojo) is a lot of non-trivial stuff to learn but SOAP is a nasty beast, if you really need to interface to a SOAP service with JS you will have to invest some time.
See:
http://www.ibm.com/developerworks/web/library/wa-dojowebresponse/index.html?ca=drs-
SOAP Requests in Dojo
Both .asmx and .svc (wcf) expose javascript enabled bindings - this is easy to find on the internet.
Example:
http://dotnetbyexample.blogspot.com/2008/02/calling-wcf-service-from-javascript.html
Normally you just append /js to the url of the endpoint and javascript providing a proxy is returned.
This proxy code relies on the ASP.NET AJAX framework, but you can easily use it with any other ajax-enabling framework by using this shim.
Having been primarily a server-side programmer(ASP.NET WebForms) I'm trying to get my mind wrapped around AJAX outside of the "catch-all" approach of using UpdatePanels in the Microsoft AJAX controls. My question has a couple parts:
Is JavaScript the only option for client-side scripting that will support server-side communication? If not what are the alternatives.
What is the "general" architecture of an AJAX application? Is it simply JavaScript(client-side script) interacting with server-side resources(data/remote functionality exposed through web services)?
I know these may seem like simple questions but given JavaScript's "nuances" AJAX still seems a bit like "black magic" to me. Thanks!
Here is the short and sweet version.
No, but it is really the only language that is supported across a wide range of browsers. If you only care about IE you could use VBScript, but it is not any extra effort to use JS and get wider support so pretty much everyone uses JS.
AJAX isn't as complicated as it seems. In a nutshell it is client side code that runs in the browser to modify the current page's layout or content based on data it queries from the web server using the XMLHttpRequest object.
The most complicated part is dealing with the different syntax/behaviors of the various browsers, which is why most people use a framework that abstracts most of that away.
Here is a simple "Hello World" script using AJAX:
<script type="text/javascript">
var http = createRequestObject();
function createRequestObject() {
var objAjax;
var browser = navigator.appName;
if(browser == "Microsoft Internet Explorer"){
objAjax = new ActiveXObject("Microsoft.XMLHTTP");
}else{
objAjax = new XMLHttpRequest();
}
return objAjax;
}
function getNewContent(){
http.open('get','newcontent.txt');
http.onreadystatechange = updateNewContent;
http.send(null);
return false;
}
function updateNewContent(){
if(http.readyState == 4){
document.getElementById('mySentence').innerHTML = http.responseText;
}
}
</script>
Source: http://www.openhosting.co.uk/articles/webdev/5899/
The final complication is parsing what you get back from the server into an appropriate form that the code can deal with. The most common optons are:
JSON: Easily parses into objects using JavaScript's EVAL function.
Nice for pulling back information
about a single entity with multiple
attributes.
XML: Somewhat easily parses using the DOM methods built into JS, but
more complex than JSON. If you need a
lot more control or want to do XSLT
transforms, this is a decent option. In theory it could be considered a little safer because it doesn't require passing arbitrary strings into EVAL which could execute malicious code on the client, but this is debatable.
Unstructured text: If you just want a single value back, the other
two methods can be a bit of overkill.
AJAX is generally the interchange, the runner if you like, of data between client-side and server-side, and of course visa-versa.
The advance of AJAX has come hand in hand with the rise of Open Source, the "Social" Web and a rapidly expanding network of developers both amateur and professional. This in turn has sparked the development of many JavaScript Frameworks (jQuery, Prototype, Mootools, Glow etc) which essentially remove, or at least mask very well, those "nuances" you mentioned.
AJAX isn't simply a client-side script interacting with a server-side script, though. XHTML and CSS for presentation, the Document Object Model for dynamic display of and interaction with data, XML and XSLT (and more recently, JSON) for the interchange, and manipulation and display, of data, respectively, the XMLHttpRequest object for asynchronous communication and then finally JavaScript to bring these technologies together (wikipedia).
AJAX/JavaScript isn't the only client side solution, other established solutions such as Java and Flash for example still have their place. But JavaScript is, for the best part, widely support by all modern browsers, and indeed the JavaScript Engines of these browsers is rapidly picking up speed, opening up many more possibilities for seamless interaction between the front-end and the back-end.
Hope I didn't waffle too much, you asked ;)
Is JavaScript the only option for
client-side scripting that will
support server-side communication? If
not what are the alternatives.
Yes, Javascript is what you will use. While there may be other options availabe such as VBScript, you will want to use Javascript because it is the most widely adopted.
What is the "general" architecture of
an AJAX application? Is it simply
JavaScript(client-side script)
interacting with server-side
resources(data/remote functionality
exposed through web services)?
That's exactly correct. Web services or generic handlers serve up the necessary data in either JSON or XML format, both of which can easily be processed with Javascript.
In my opinion, the thing about AJAX that slips up most ASP.NET web form developers is the asynchronous aspect.
All the current answers are good but they neglect one point. AJAX is not a script or language or technology as such, you cannot write something 'in' AJAX. AJAX is just a bundling term.
This is from Wikipedia:
Like DHTML and LAMP, AJAX is not a technology in itself, but a group of technologies. AJAX uses a combination of:
HTML and CSS for marking up and styling information.
The DOM accessed with JavaScript to dynamically display and interact with the information presented.
A method for exchanging data asynchronously between browser and server, thereby avoiding page reloads. The XMLHttpRequest (XHR) object is usually used, but sometimes an IFrame object or a dynamically added tag is used instead.
A format for the data sent to the browser. Common formats include XML, pre-formatted HTML, plain text, and JavaScript Object Notation (JSON). This data could be created dynamically by some form of server-side scripting.
JavaScript alternative VbScript ( if I have to name one and beware it is MS technology and works only with IE ), But practically speaking JavaScript is universally accepted solution for client side scripting.
For Ajax Please refer below SO discussions :
ajax-books-and-tutorial
ajax-tutorial
ajax-and-asp-net-tutorials