I would like to have a page where a restaurant can log in and see all of their current reservations/take-out orders, and I want this page to automatically update when someone (from another computer) makes a reservation or places an order. The idea is that the restaurant would leave this page open at all times to show their current status. What is the best way to do this? Can it be done without refreshing the page?
I wasn't even sure how to refer to a setup like this, so I wasn't really able to find much using Google. Is there a word for this type of setup?
I am using rails, and I am considering using AngularJS for the front end. Any suggestions?
There are two approaches to solving this.
The first, oldest, simplest is that your webpage contains some javascript that will poll the server at regular intervals (e.g. every 10-30 seconds), to check if something has changed and then add the changed data (e.g. reload a partial).
The second approach is a bit cleaner, and it allows the server to push the changed data to the connected clients, only when it is changed.
There are a few available approaches/libraries for this:
use websockets
use pusher
use juggernaut The author of juggernaut had deprecated it, in favor of using HTLM5 SSE (server sent events). Read more.
The advantage of using polling is that it is easy, works on every browser, but you have to write more code yourself, you will put some kind of load on your server, even if data has not changed (although the load is minimal).
The push-technologies are newer, work very clean, less code is needed. But some work only in newer browser (most of the times not really an issue), and some require extra support/setting up on your server-side.
On that note: pusher is really easy to get started with, and if your load is limited, it is free.
There are still a lot of others, but this should get you started in the right direction.
Suppose I am writing a simple single-page web application in JavaScript. The application just displays employee records. User enters search parameters, the application fetches employees records from the server using AJAX and displays them in the web page.
The application state is search params and employees. How to store them in the application? I see two options:
just use DOM to store the state implicitly.
create data structures for search params and employees and synch them with the DOM.
Does it make sense? What are the pros and cons of these two options?
If you are targeting modern browsers, Web Storage would be a good option for you to look into.
Good write up here: http://sixrevisions.com/html/introduction-web-storage/
That way all load would be kept within the client and data would persist between requests and if user leaves and comes back to application.
The options you mentioned which I'm guessing means you would store data within hidden DOM elements would be easy to develop however you will lose all persistence. If you're going to go down this path, why not just store the data directly in javascript objects?
Another good read: http://diveintohtml5.info/storage.html
Definitely the latter. The DOM was never designed as a data structure. On the other hand, creating an architecture to keep the DOM in sync with your custom data structure can be a pain.
Luckily, there are frameworks that can help you with this. Most of these follow an MVC- (or MV*)-like design pattern. Examples include Backbone.js, AngularJS, Spine, Agility.js, JavaScriptMVC and many others. Have a look around.
Also check out this project: TodoMVC. It might help you decide whether to use a framework like this and, if so, which one.
If you want them to be persistant, you can't use the DOM, and you shouldn't. HTML is for your user interface and linking everything together, not for data storage of your app. You have a couple of options. You can use global variables in your JavaScript, but you have to remember that they will not persist between visits to your page. If this is what you want, go ahead.
Another option is to use HTML5's Local Storage, which is persistant and designed for storing data.
Your last option, which is important if you don't want to store the data locally but do want to persist it, is to use HTTP AJAX GET and POST with a servlet or something on the client side that gets and sets the data, respectively.
If you want to go the old way, you could also use cookies instead of Web Storage. I definitely suggest the later though.
In this case, you can trigger a change in your hash when user applies a filter. For example:
http://www.mydomain.com/index.html#name=abc&department=def . Your app listens for changes in the hash to update accordingly. Libraries like: crossroads.js, sammy.js allow you to to that. This approach on client side borrows the routing concept on server side.
Using this approach, you can send the url to your friends to "jump" directly to a specific state of your application and you can also reuse it, store it anywhere.
You might consider using this kind of leverage if you use HTML 5 :
http://www.jstorage.info/
I want to add Excel button below the html table, that gives an Excel sheet of the table. I am using C# behind it, but I want it do on client side just using jQuery or Javascript without using PHP or .NET... Not more.
I am searching for hours however I don't find any fix solution. There it said you can use activeX object and CSV however I don't see any running examples.
ActiveX will only run on Internet Explorer so your solution will be limited to that platform.
Without ActiveX or server side scripts there is no way to achieve this due to JavaScript security designs it is not allowed to create files or push in memory files to download streams.
I would not recommend ActiveX or anything that tries to run code outside of the browser on the client system. ActiveX only works on IE not to mention the inherent security risks that brings about.
A possible method would be to use a server side script along with jquery to generate the file and return it without ever leaving the page your on. It looks good and you don't really have to jump through hoops to make it work nor will the user. (if you want an example of the jquery required to do this let me know).
For c# there is alot of tutorials on generating excel files from your data for example here.
The only reason I can think of that you would want to create the file locally is use of resources on your server. C# will be extremly efficient in generating that file not to mention there are a couple things you can do (dependant on the data) to negate any impact it has:
If the data changes are few and far between consider storing the
generated file and directing to that the next time until the data has
been changed.
Limit the data set it returns by way of a search criteria
There are plenty more optimization you could do but you get the idea.
I've created a list using XML and have embedded an XSL stylesheet in it. Now I want to know, because this is a list of movies that constantly grows, is there a way to create a form that will add child and grandchild nodes to the list.
I'm thinking there might be some javascript involved, but I have no idea what I'm doing when it comes to scripting.
If the intension is to write new entries into this xml file you need to look at some form of serverside scripting. Javascript can not write to files.
PHP is probably the easiest to understand, start by buying a book that explains the basics with a few examples, it's not that hard to grasp, and a form and a simple function for writing to files shouldn't take you to long to figure out.
If you have no interest in that sort of thing, hire someone to do the job for you, it will probably only take a few hours for someone who knows what they are doing to get a complete system up and running for you, and unless you really would like to learn a serverside language that is probably the best option.
If you really want to do it all on the client side, you can try HTML5 client-side storage. This means the data will be persistent only for the user that enters the data (and only for the browser used to enter it, and only on the computer that was used).
If you want the movies to be accessible to multiple people, or from multiple computers, you need to use server-side storage.
FYI, HTML5 storage is not yet very well standardized across browsers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm building a web application with the Zend Framework. I have wanted to include some AJAX type forms and modal boxes, but I also want my application to be as accessible as possible. I want my application to be enhanced by AJAX, but also fully functional without AJAX.
So as a general guideline...when should I not use AJAX? I mean, should I bother making my application usable without AJAX? Or does everyone have AJAX enabled browsers these days?
If you mean "accessible" in the ADA sense, AJAX is usually a no-no - your site should provide all its content and core functionality using only standard (X)HTML and CSS. Any javascript used should merely extend the core functionality, and your site should be coded to work elegantly in the absence of a javascript-enabled browser.
Examples: if you want a user to click on a thumbnail and get a full-size version of the image as a result, you can make the thumbnail a link. Then, the onclick event will fire a JQuery method that cancels the navigation behavior of the link and pops up a JQuery floating div to show the image on the current page. If the user's browser doesn't support JavaScript, the onclick event will never fire, and the user will be presented the image in a new page. The core functionality is the same with or without scripting.
EDIT: Skeleton example, sans JQuery-specific code.
<html>
<body>
Some URL
</body>
</html>
To cancel the navigation operation, simply make sure that the method invoked by the onclick event returns false at the end.
A neat example of the JQuery image popup I described can be found here.
Use ajax if it adds value for the user.
If the ajax version adds a lot more value than the non-ajax version then it might justify the expense to develop a solution that caters for both clients. Generally i wouldn't recommend doing the extra work (remember.. more code results in more maintenance).
I think one point is missing here: Use Ajax only for content any search engine does not need to know.
98% of users will have AJAX enabled browsers.
A significant percentage of those people won't have it turned on when they first visit your site though (or at all, ever perhaps).
I've seen websites that look like a blank page without javascript on. Don't be one of them. Javascript to fix layout issues is a horrible idea in my opinion. Make sure it loads and looks ok without Javascript. If people can atleast see what they are missing out on, they are likely to switch it on, but if your website looks like it's just broken, then...
I often have noscript block Flash and JavaScript until I make the decision that your site is worthy.
So be sure to tell me what I'm missing if I have JavaScript turned off.
It depends on the complexity of your web application.
If you can, having it functional with javascript disabled is great, because it makes your application usable not only by users on js-disabled browsers but also by robots. The day you decide to write an application to automatically fill your forms, for example, you don't have to write an API from the ground up.
In any case, do not user AJAX for EVERYTHING! I have just inherited a project that basically consists of a single page that is populated by a ton of AJAX calls and I can tell that you just thinking about it gives me physical pain. I guess the original developer didn't like the concept of using the back/forward button in the browser as a mean of navigation.
Unless you are targeting mobile devices or other non-standard web users, you can be fairly sure that the vast majority has Javascript enabled, because most major sites (including SO) rely heavily on it.
I want my application to be as accessible as possible.
You can do things like rendering your modals and forms as a page that can operate standalone.
The AJAX version pulls the template into a modal/container, the standalone version checks if it's an AJAX request and renders the page including the header/footer (this can occur from the same URL if planned well)
The AJAX version intercepts the submit and does AJAX submission then provides an inline thank you, the non-AJAX opens a thank you page. Once again you can likely use the same pages for each of these functions if thought out correctly.
Reusing templates and URL's helps avoid additional maintenance for the AJAX/non-AJAX versions.
I want my application to be enhanced by AJAX, but also fully
functional without AJAX.
Thinking through the structure of your URLs and templates can go a long way towards this, if you make most of your AJAX requests pull in completely rendered templates (as opposed to just data) then you can usually use the same URL to serve both versions. You just serve only the guts of the modal/form to the AJAX request and the entire page to a regular request.
When should I not use AJAX?
You should not use AJAX if doing so will cause a poor experience for a significant portion of your user base (there are of course techniques that can be used to mitigate this)
You should not use AJAX if the development time associated with implementing it will be too significant to justify the improvements in user experience
You should not use AJAX for content which has significant SEO value without implementing an appropriate fallback that allows it to be indexed (Crawlers are improving constantly but it's still a good idea)
I mean, should I bother making my application usable without AJAX? Or
does everyone have AJAX enabled browsers these days?
I'd say a lot of the time it's unnecessary as the vast majority of users will have AJAX enabled browsers, but there are scenarios where it's critical such as SEO optimization or when a large portion of your user base is likely to use browsers that are less likely to support Javascript as well or where they're likely to have Javascript/AJAX disabled.
A few examples of these scenarios:
A website for a company or government that uses an outdated browser as standard
A website where a large portion of the users may be disabled in a manner that may negatively impact their experience such as a website for vision or motor-skill impaired people may be negatively impacted by updating content via AJAX especially if it occurs rapidly.
A site accessed regularly via a less common device or browser that will cause a negative impact to a large portion of users
So what should I do?
Think about who is going to be using the site, how they're going to access it, and what they're going to access it with. Also try to think about not just the present but also the future.
Design the site in a manner that will cater to the majority of these users.
Think who will gain and who will loose based on my decision to use AJAX and if in doubt have a look at your analytics data to help weigh up the decision and if you lack the data it may be worth updating your tracking and obtaining a sample to aid the decision
Think does my decision to use AJAX cause any contradictions with core requirements for this project
Use AJAX to enhance content where possible as opposed to making it mandatory ie the content should work with or without JS/AJAX
Consider the additional development time involved with the use of AJAX (if any)
My experience is, we should use ajax after it works without it. For a couple of reasons.
First, if something breaks in the ajax, and you don't have it working without it, the site simply doesn't work. For example, a product list with pagination. It should work with the links alone, then use ajax when possible.
Second, for site indexing and accessibility. If it works without ajax, it's better.
And it's easier to break something (even if only for a few moments). A bad piece of code, an uncaught exception, an external library not loaded, a blocking browser extension,...
After everything works without ajax, its quite easier to add ajax. Just have the ajax catch the action, add ajax=1 and when returning the result, return only what you need if ajax=1, otherwise return everything.
In the product list example, I would only return the products and pagination html, and add to the correct div. If ajax stops working, the whole page is loaded and the customer sees the second page as it loads.
Ajax adds a lot of value to UX. If done right, the user gets a great feel when using the site, and better data usage because it doesn't load the whole page everytime.
But the question being "when not to use ajax", I would say, you should always count on it to improve UX but not rely on it for the site to work (as other users also mentioned). And nowadays we need both, great code and great user experience.
My practice is to use two main pages, let's say index.py and ajax.py. First one is responsible for generating full website, and is default target of forms. Other one generates only output specific for adequate ajax query. Logic behind both of them is the same, only the method of generating output is a bit different.
In jquery I simply change action parameter when sending a request. It works both with and without ajax, although long time have I not seen someone with disabled js and ajax.
I like the thought of coding your application without JavaScript / Ajax and then adding it in later to enhance the UI without depriving users of functionality just because they don't have JavaScript enabled. I read about this in Pro ASP.NET MVC but I think I've seen it elsewhere in reading about unobtrusive JavaScript.
You should not make your service bloated with web 2.0 effects like accordion, modal/etc forms, image zoomers etc.
Use modern tech smarter (AJAX is one of them) and your users will be happy. Do not fear AJAX -- this is very good thing to make user expirience smooth. But don't do things because you like it - do them because your user need it ;)
When you want to make a website that looks like a website, not a fugly imitation of a desktop app?
You should not use AJAX or JavaScript in cases where:
your system needs to be accessible
your system needs to be search friendly
However, by using a modern JS framework with some solid "unobtrusive" practices, you can progressively enhance pages so that they remain accessible and search-friendly while offering a slick UI to users.
This totally depends on the type of application or feature you're developing. If it is crucial that the application is accessible despite the absence of Javascript, then it would help to have fallback methods (i.e. alternative forms) to allow your user to use said functionality/feature. For that, it will require you to invest some of your time developing methods for collecting information not just using client-side scripts but also on the server-side.
For miscellaneous features that only serves to enhance user experience, it's mostly not worth it to develop fallback methods.
There's no reason to totally not use AJAX. AJAX helps minimize your traffic after all.
You can if you wish always use AJAX and update the history state using Push State or for more compatibility use the hash with none HTML5 compliant browsers.
with this you can have your server load a page then javascript read the document.hash and resume the state of the application base on the state of the hash.
for example i got to /index.html i click into something for example a client to open the view client you can change the hash to #/view/client/{client_id}/ then if a reload or go back using the browser the hash with change and you can use the onhashchanged event to capture it and match the sites state to the new hash then same if a favorite a certain state
A couple of other scenarios where one may be better off NOT using AJAX:
Letting someone to log into the web application. Use traditional form submit instead.
Searching and returning more than a few 100 rows from the database. Either break the process down or let the server side language handle it.