I'm trying to support a user base that is tied to IE8 currently and noticed that I can't use the 'DELETE' or 'PUT' verbs. Will using modernizr allow me to do this in IE8? If not what library if any will allow me to do this w/ out a hacky work-around like passing the verb in post data
According to answers to this (old) SO question, you shouldn't have a problem with DELETE and PUT if you use them via the xmlHttpRequest object (ie Ajax calls).
In addition, the Wikipedia page for xmlHttpRequest also states that all the verbs are supported from IE7 upward.
They aren't supported from a straightforward form submission, but there's not really much need to use them in this context; POST should be sufficient. But for Ajax calls, you should be fine.
I recommend trying it in IE8 to confirm, but I don't think you'll have a problem.
Given that, I don't think you'll have a need for Modernizr to help you with this, unless you need IE6 support. But just to be sure, I had a look at the Modernizr docs, where it lists all the feature detections it does, and I couldn't see anything about http verbs. And even if Modernizr did detect it, you'd still need a polyfill to actually fix it, and I don't know of anything that would be able to do that. .... So it's a good thing you probably won't need it, then.
Related
If I have Ajax code on my website:
1) Is it still necessary to check if a user's browser supports Ajax? Don't they all?
2) if so, is there an non-ActiveX approach to check this? I'd really like to avoid ActiveX as some security filters could flag it as potential malware.
It's not a question of if browsers support 'ajax', this is just a pithy term used to describe the process of a client retreiving data from a server via Javascript, typically asynchronously, and typically using the XMLHttpRequest object.
This object is not defined by IE 5-6, so you have to write code to compensate, or use a library such as jQuery which encapsulates this.
So, what you should be asking is whether your site gracefully degrades if Javascript is not available on the client. i.e. can users still get to the content without Javascript?
The jQuery AJAX call has a type parameter that allows to specify the method for an async call (GET/POST/PUT/DELETE); documentation states that:
The type of
request to make ("POST" or "GET"),
default is "GET". Note: Other HTTP
request methods, such as PUT and
DELETE, can also be used here, but
they are not supported by all
browsers.
What does this mean for modern browsers? Can I count on jQuery AJAX to make fully RESTful calls, which rely on the PUT and DELETE verbs?
Yes. $.ajax makes the dirty work to allow PUT and DELETE.
Here you'll find more info: Are the PUT, DELETE, HEAD, etc methods available in most web browsers?
I know it's an old question, but I keep on coming here when searching for the browsers HTTP methods support. I never found anything saying exactly which browser supports which call. The link provided is not clear on it too.
Because of that sentence in jQuery manual (they are not supported by all browsers), I've stayed clear for a while of PUT and DELETE and tried to limit myself to GET and POST. However, today I decided to run some tests with IE 6 for a rest API I'm developing and I didn't have any problems to use also DELETE.
If it works in IE6, crappy 2001 technology, it is pretty much likely that it will work everywhere and that sentence on jQuery manual is pretty much obsolete.
I will update this post in the future with further tests. If anyone knows of a browser not supporting ajax calls for PUT and DELETE, I would like to hear.
Facebook is doing Ajax History (Back and Forward button) and Bookmark using #! instead of just # in the URL. Is it always a good idea to do that, because I was thinking that a usual anchor could interfere with the Ajax History mechanism to trigger it into processing a normal anchor.
So, the Ajax History function will only process a hash portion only when it sees #! instead of just #.
And is using ! compatible with major browsers? If Facebook is using !, a guess is that it may be fairly well supported.
See Google's Making AJAX Applications Crawlable
for a possible use case (don't know if this is why Facebook used this fragment).
Update: This answer has been superseeded by this article. It discusses the issues with the Hashbang (#!), Hashes (#) and the HTML5 History API (pushState, popState) and the solutions.
In regards to usability on your website, it doesn't matter and you can use anything you like.
In regards to search engine optimization, having it and not having it both provide different avenues to go down.
For instance, Facebook uses the ! according to the Google Proposal for Making Ajax Applications Crawlable. Adding the ! will tell google that it should listen in on that ajax request and add that url to search engine results. This is great for websites which have already implemented ajax, as all you need to do is add the !.
The downside of this is that it only solves the problem of making your ajax crawlable. It does not solve the problems of:
Keeping the URLs clean and consistent for Ajax and Non-Ajax users. Eg. you could end up with www.facebook.com/profile.php?pid=123#!profile.php?pid=123
Keeping the website accessible by Non-Ajax users.
Keeping the URLs the same for both Ajax and Non-Ajax users.
Requires some severely complicated server side changes for escaping and translation of states in regards to query strings.
It is not compatible with the new HTML5 PopState functionality which is designed to truly solve these problems.
For websites which don't currently use ajax for everything, due to the problems above it is far better NOT using the Google Proposal as it is only workaround for sites like facebook which went ajax crazy and needed a desperate solution to SEO. There are alternatives which solve more of these problems (and with the HTML5 PopState now available can solve all the problems). One such alternative is jQuery Ajaxy (as seen on balupton.com) which works by simply upgrading your website into a ajax application, while keeping the experience for a Ajax-Enabled rich and interactive and continuing to work perfectly for Ajax-Disabled users.
I want to capture the responseXML that i have built in my jsp.
What should I do.
after that i will transform it in html.
I know this is annoying and we could do it with a framework or a library like jquery but i realize it with ajax.
Also i have problems with jquery and jsp\servlet since i must use a JSON SERVICE.
Why it seems to me that is so complicated.
It doesn't need to be that complicated. You maybe just need to align all the technologies out one by one yourself. JSP, Servlet, JavaScript, HTML DOM, HTML and Ajax are all separate technologies which needs to be learnt and understood separately. Trying everything together at once without understanding them separately will indeed likely lead to more confusion, complication and frustation as you encountered. Follow the given links to learn about them separately. Learn walking before running or cycling.
The jQuery library just removes the need to write/duplicate all the code to keep it all crossbrowser compatible. Only executing an Ajax request the crossbrowser way is already far over 10 lines of (well-writen/indented) code. jQuery brings it to an minimum, an oneliner is possible.
To learn more about the wall between JavaScript/Ajax and Java/JSP/Servlet, you may find this article useful. I've posted several answers before how to get JSP/Servlet/Ajax to work together (although in combination with JSON and jQuery, but almost everyone will agree that JSON and jQuery are the way to go; JSON is easy to generate/parse in Java using Google Gson and is easy to build/access/process in JavaScript as it is the language's own nature; jQuery is actually a revolution in the way you use JavaScript). Here's a good starting point to find code examples I posted before.
Hope this helps.
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