I am coding a backwards compatible file upload progress for AJAX. In HTML5 there is the xhr.upload.progress event; this would be an alternative for non-XHR2 browsers. I am using the APC extension to monitor the progress.
Now, my question is: which is the best method for firing a custom-built xhr.upload.progress event? I plan to use HTML5 SSE's, but if they are not supported, I'm not sure what I should fall back to.
Polling: continuous AJAX requests for the progress every couple seconds
Long-polling: apparently better than polling? though, I hear they cause the server to freeze up, because the requests aren't really handled asynchronously on the server. So, I'm assuming I would have to implement something like NodeJS to avoid that. If the freezing-up problem has just been overstated/overdramatized, I'd probably go with long-polling.
Un-ending iframe: the iframe seems like a good idea, but I'm sure there are problems with it. Does it freeze up the server like long-polling too?
Edit:
I guess, here are my primary concerns. What is the scalability of these AJAX methods? Do EventSource SSE's freeze-up the server's memory as well? If so, should I consider using something like NodeJS or ScaleStack? And, does server overhead really matter with an upload bar?
All these solutions require you to do some server-side work too while the best solution would be client-side only. For now, I'm using a Flash component Uploadify to do that job.
http://www.uploadify.com/
For convenience, you may use SSE polyfill as a fallback: https://github.com/Yaffle/EventSource — you won't have to write extra code for non-SSE browsers.
A completely different approach could be to track upload progress in JS, client-side. Relatively new XHR2 and FormData APIs make that possible.
Related
I'm currently using express-static to serve static content, and express-resource to handle all of the ajax requests coming from my backbone models. I want my site to feel alive, so obviously it's time to throw some websockets (socket.io) at the problem!
While doing that, I've noticed a lot of redundancy in my code, and am not convinced I need all these ajax calls anymore. I've been contemplating replacing my ajax requests with websockets entirely!
Seems pretty straightforward, replace the default backbone.sync with socket.emit calls. ezpz
My question is, are there any thoughts on the proper way to do resource management (like in express-resource) with websockets?
My best thought is to have urls that include the "action" (new, create, show, edit, update, destroy), such as "show/resourceName/resourceId" or "destroy/resourceName/resourceId".
Any thoughts? All opinions welcome! (As a note, I'm ok with the fact that this won't work for some mobile carriers, ancient versions of IE, and other constraints that are frustrating to us developers)
Not sure if you've already seen this or not, but there's a project which is an override of Backbone.sync and a server-side component using socket.io:
https://github.com/scttnlsn/backbone.io
If its not directly usable for you, it certainly contains some ideas and guidance.
I need for users to upload files (mostly images) without leaving the current webpage. What's the best tool, library or mechanism for doing this? I'm using the latest jQuery and Spring webmvc (with JSP), so if there's already a mechanism within them then that's ideal.
It would also be really great to have some kind of progress bar. Does that mean it requires coordination with the server to read the progress (where Spring would have to come into play)? Or is there a mechanism within JavaScript for this?
You should check out Plupload.
Plupload offers a cross-browser
JavaScript File uploading API that
handles multiple file uploads,
client-side progress meters, type
filtering and even client-side image
resizing and drag-and-drop from the
desktop. It achieves all of this by
providing backends for Flash,
Silverlight, Google Gears, HTML5 and
Browserplus and picking the most
capable available option.
Its really neat! Here's a link to some of their Demos...
http://www.plupload.com/example_jquery_ui.php
... and a screenshot of the jQuery UI queue widget (it has a progress bar!):
I hope this helps.
Hristo
I use uploadify pretty regularly: http://www.uploadify.com/
However it does use flash for the upload mechanism and as a result may create some issues if the user is authenticated.
You should use AJAX on the client side
http://www.webtoolkit.info/ajax-file-upload.html This tutorial covers all client side.
Om the server side
This tutorlal covers most of this issue:
http://www.ioncannon.net/programming/975/spring-3-file-upload-example/
Yopu can use jquery as well or any other JS framework.
But the mist important thing is the fact You need to remember that your tag on client side should have.
enctype='multipart/form-data'
property. it means that your request contains muultipart data.
Uploadify does that trick > http://www.uploadify.com/
All samples are php but you should be able to convert it to your platform.
I have a partial template that I want to intermittently poll the server (one of my controllers) and update its display with the result.
What is the appropriate way to do this with grails?
I have seen some articles saying there are specific grails tags for ajax calls, which would be nicer as it would allow clean direction to a controller/method, however, I've not seen anything in Grails to suggest that polling of a controller method could be done altogether.
Thanks!
There's nothing built into Grails that will do the polling for you. The most basic way is to simply use the setInterval() function in your JavaScript. If you're using a JavaScript library then something might be available there that would make things easier on you.
As a side note, be careful when implementing polling. If you're application isn't scaled correctly and you expect a lot of users, polling can bring your system down quickly.
Are there any disadvantages to using AJAX?
No integration with the browser's history.
If you build a site that requires Ajax to see content and perform tasks, you have several major problems. Ajax-only content/functions are invisible/unavailable to:
search bots
many mobiles
people with Javascript turned off
etc etc.
However, if you build a site using the progressive enhancement principle, those problems are solved, and you still get to serve nice-to-use Ajax to most users.
Progressive enhancement involves first creating your site using bare-bones (X)HTML, on REST-like principles (at least to the extent of requiring POST requests for state changes). Simple semantic markup; forget about CSS and Javascript.
Step one is to get that right, and have your entire site (or as much of it as makes sense) working nicely this way for search bots and Lynx-like user agents.
Then add a visual layer: CSS/graphics/media for visual polish, but don't significantly change your original (X)HTML markup; allow the original text-only site to stay intact and functioning. Keep your markup clean!
Third is to add a behavioural layer: Javascript (Ajax). Offer things that make the experience faster, smoother, nicer for users/browsers with Ajax-capable JS... but only those users.
Browser compatibility.
Asynchronized access to data means it's harder to make things go correctly in every combination of actions.
Dependency of javascript makes the site unusable for some. Also javascript performance can be a bottleneck in resource limited environments.
User may not know via the client that an AJAX operation was made, or if it failed. It can be difficult to recover from client side errors caused by a failed AJAX call.
Makes it really Hard to do functional testing .
Inability to update the client without "polling", which means querying the server every X seconds.
It requires javascript. And you have to admit to your friends how "Web 2.0" you are. Instead of being hard core old school: It's all tables for layout and frames for navigation for me.
Yes, Ajax is not supported by old browsers or browsers which don't have javascript enabled. Nowadays, most of the browsers do have support for Ajax -- even mobile browser like the one on the IPhone.
The biggest issue for me is that Ajax adds complexity to the project.
There are many ajax libraries out there, which are suppose to make life easier. In most cases, these libraries are easy to use to create a "Hello World" application. One of the main issues which is most of the times kept asside by Ajax libraries is (client-side) error handling/logging.
For larger projects, the developer has to understand the internals of the library, which adds a new learning discipline to the project.
Some of our big clients -for security reasons- took a corporate decision of having javascript switched off. Therefore no AJAX is possible.
If you are going to develop something using AJAX for a given client be sure that your client are allowed to use javascript.
Restrict your application to a reasonable number of browsers and browsers versions.
Crossbrowser compatibility can make your life miserable.
Ultimately, the problem is that it introduces is complexity. Most problems inherent with AJAX sites (bookmarking, browser history, graceful degradation, etc...) can be overcome with a good design, so there are not really any disadvantages to a well designed AJAX enabled site. The problem is a creating such a site requires a lot of design and very good developers who can manage the complexity.
Our team is experienced in web development (tomcat/Oracle) but not with AJAX on our existing projects. This is new technology for us, so I want to introduce this carefully and correctly.
What should I look at in terms of frameworks or best practice or common pitfalls?
read this:
progressive enhancement
and use a library such as jQuery, mootools, or YUI it'll save you many headaches with cross-browser implementation. this will show you why you want to use a library.
My first recommendation would be to explore the different frameworks available and see what your team prefers in terms of coding style. Most of the frameworks have the same basic features so a lot of it comes down to preference. I prefer jQuery, so that is my first recommendation, but I worked with YUI, MooTools, Prototype and EXT JS before making my decision.
Secondly, I would recommend working AJAX functionality as a progressive enhancement, allowing your apps to work with and without JavaScript. I find that this approach also ensures a solid, working application before worrying about adding the bells and whistles.
Head First Ajax is a good book IMO for getting started with the basic concepts behind working with Ajax. It would probably be a good place to start for your team to gain some knowledge of what is happening behind the scenes in whatever framework you choose.
One thing we struggled with when starting to use ajax was how often to use it.
We had no exact requirement as to where we were supposed to use ajax and not, and initially we erred to the side of using it too much. This affected application complexity quite a lot.
If you think of your inter-page-structure as a state-machine, ajax introduces nested state-machines within each page-state. The moment your sub-state machine ends up with a number of distinct states (I'd say anything over 2), you should think really hard about using a traditional approach.
The best starting point is to try to get a mix og full page reloads and ajax, and be conservative until you're sure you're getting really good at it.
Don't use it where you don't need it.
Long running operations that need to send the client some status updates? Use AJAX.
Markup for major UI elements (menus, ect)? Use plain old HTML.
Basically, use AJAX for transmitting data only. If you try do fancy things like dynamically pulling in UI elements on the client side with AJAX, you are in for a world of hurt when you get a client who wants to use ie5 (they exist), or a non-pc based browser.
first, look at the user interface you already have, and consider where it might make sense for its elements to be able to change/react independently. This is where your ajax enhancements might make sense
second, look at libraries as noted in the other answers (I like AJAXPRO for its simplicity, but it has been discontinued)
if you find that all of your page elements tie together and cannot change independently, then there is really no need for ajax
otherwise, consider how you will access the page state from your ajax enhancement points - depending on which ajax framework you use, you may or may not have access to the entire page object, session state, original request parms, etc. Consider these issues up front to avoid coding yourself into a hole and/or having to make messy workarounds.
If you were on .Net or Mono I would encourage you to use Ra-Ajax which abstracts away JavaScript completely. Though I work for Ra-Ajax (inventor) so I am biased...