I have a backend where people may take some time filling out the form. The form is written to a temporary table every 5 minutes to store the data. The problem I have is that some peoples internet connections are not strong, so they drop at times without the person knowing and when they go to submit, the form can't because of loss of connection. Every 5 minutes I was going to add if the ajax fails, then prompt the user, but I want to go further and possible allow them to store the data offline and then reconnect to submit it.
The problem is, how would I start storing the data to a file on their local machine? As far as I know, client side scripting can't create files and we couldn't use ajax to call a remote file that saves to a local file. I suppose I could prompt to save the file at the beginning locally, but the local machine still would need to support the language. We are using JSP with MySQL.
Does anyone know of how I would accomplish saving data offline when a connection drops?
Implementing offline capabilities can become a tough exercise. Your question is too broad to provide a final answer, but you should have a look at HTML5 capabilities, an overview is available here. Using this feature requires your users to use a modern browser version. You have to think of synchronization/replication as well.
If the connection only drops for a limited amount of time, it may be enough to just use a rich-client and store the data in memory using JavaScript.
Something like this should do the work :
First way:
Use HTML5 localStorage/session storage, or something like Gear to
save the data on the client side
Make an ajax loop to ping the connection, idealy the server should be configured to reply with a http code 100 (I presume)
Send the data when the connection is on
Second way:
Use HTML5 offline capability or a substitue (see modernizr and polyfill)
Related
I have a large Photoshop script (written in Javascript) that accepts parameters from me and then generates unique software files and mockups to client specifications. What I would like to do is create a form on the company website for new clients to fill out and then when the form is submitted, have my Photoshop script execute automatically, thus eliminating the need for me to manually enter clients' custom parameters. What I am wondering is if it is at all possible to do this. I would need to somehow track the event as it goes to the server hosting the website and then relay that to my work station. Or, would I have to use my work station as the server (at least for the form)?
I am hitting a wall when it comes to online research so if you don't have an answer, but perhaps have a keyword I have yet to google, that would be appreciated too! Thank you for your time spent reading this.
Details on the "parameters:" The data that needs to be sent consists of Strings and Numbers only. While it is impersonal and does not need encrytion, it could (in some cases) be way to long to fit using the GET method.
Side note: My most current research has lead me to investigate JSON.
I am not sure if I understood your problem :) , but if your problem is to transfer information from server to local machine for processing you can try :
1) store the submitted form on server in file or db,
2) write another script on your local machine that will run every 10 minutes for example (you can do it via cron job in linux) which will grab the new inserted data from server and pass to your photoshop script or store in local machine.
Or you can do by nodejs, I mean
1) the script from local machine connects via socket to the server and listens for new events
2) after each new substitution from website the script receives data from socket and runs photoshop script with given parameters
I am building applications that are used on a touch screen in an educational environment. The applications gather data from user input. The data is then send to a server. There are multiple units, and whilst exact synchronisation is not paramount, the gathered data (along with other data collection from another source) will be combined and distributed back to the touch screen applications.
The applications are being build in Backbone with initial data loaded from a single JSON document. The JSON document is parsed from a remote MySQL database, which is downloaded (along with assets) on initialisation.
Whilst when possible the app should send new data back to the remote mySQL DB as soon as it is gathered, this may not always be possible and I need to collect the data so as to send it when I can.
My first thoughts are that storing everything in localstorage and syncing whenever possible (clearing the localstorage each time a successful sync takes place) is the way to go.
Over the bank holiday weekend, I have been playing meteor.js, and I think that maybe if I write my localstorage solution I will be reinventing the wheel, and a tricky wheel at that. It seems that Meteor.js has a way of mimicking a database offline, in order to fake instant updating.
My question is: How can I use a similar technique to add some offline protection? Is there a JS framework, or backbone plugin I can utilise, or a technique I can tap into?
You can use Backbone.localStorage to save your models and collections to the local storage, while the connection is offline.
Detecting if your user is offline is as easy as noticing that your xhr requests are failing. (https://stackoverflow.com/a/189443/1448860e).
To combine these two.
When you suspect the user is offline (an ajax request to your backend gets no response), switch Backbone.localStorage and store everything there. Inform the user!
When the user gets Internet connectivity again, save any changes from localStorage to the server. Inform the user again!
Voilà!
Introduction:
App must be able to run completely offline, store data locally and post it online via AJAX whenever there is an internet connection available - this may be some days later.
Question:
How to store data using Javascript?
Additional notes:
I don't want to use any server-side technology.
It must be secure like a database. I've read about cookies and html5 storage but none of them sound convincing.
If you are supporting modern browsers, you can make use of HTML5 Local Storage.
Persistent local storage is one of the areas where native client applications have held an advantage over web applications. For native applications, the operating system typically provides an abstraction layer for storing and retrieving application-specific data like preferences or runtime state. These values may be stored in the registry, INI files, XML files, or some other place according to platform convention. If your native client application needs local storage beyond key/value pairs, you can embed your own database, invent your own file format, or any number of other solutions.
Example
// Save data to a the current session's store
sessionStorage.setItem("username", "John");
// Access some stored data
alert( "username = " + sessionStorage.getItem("username"));
// Get the text field that we're going to track
var field = document.getElementById("field");
// See if we have an autosave value
// (this will only happen if the page is accidentally refreshed)
if ( sessionStorage.getItem("autosave")) {
// Restore the contents of the text field
field.value = sessionStorage.getItem("autosave");
}
// Check the contents of the text field every second
setInterval(function(){
// And save the results into the session storage object
sessionStorage.setItem("autosave", field.value);
}, 1000);
Browser Compatibility
Older Browsers
Use Polyfill.
Depending on how complex your data structures are that you want to store you could look at indexedDB. It's availability is still pretty bleeding edge but with a polyfil you can target the majority of modern desktop and mobile browsers.
The data stored is no more secure than any other client storage model since it's meant to be read with JavaScript.
The API itself is pretty complex to dive straight into using so you might want to look at wrapper APIs such as PouchDB which syncs with CouchDB or if you want something much simpler there's db.js.
You can use HTML5 Local Storage
Use polyfill for older browser
https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#web-storage-localstorage-and-sessionstorage
Exactly what you want:
You can set up a CouchDB instance on IrisCouch to store your data. CouchDB is a database that acts as a webserver, so it can serve html pages based on its own data -- this use of the CouchDB (to serve pages) is commonly called CouchApp.
So you learn about CouchDB and write a HTML/Javascript/CouchDB-flavored app to serve your page. There are tools that facilitate this.
After that, you only need to send the data to your CouchDB database and it will be on your web page. You'll manage the client side stuff with PouchDB, a implementation of CouchDB that runs on your browser and saves your data locally, so you never lose it, and automatically updates your local data on the CouchDB server and vice-versa. It's the bleeding edge of the offline storages on the internet.
To ensure that the clients will not send bad data to the server, you can set up authentication (so to connect Pouch with Couch you will need to provide a password) or you can set up validation functions (so the server will only accept data storage requests that match certain parameters you define). These two approaches are well explained in the guide I linked before (here), but you will certainly run into all of this during your CouchDB learning process.
A lot of stuff, but a cool solution enough for the trouble. Also, this CouchDB thing is so easy I can bet you'll read and learn everything in one or two days.
I'm working on a web based form builder that uses a mix of Jquery and PHP server side interaction. While the user is building the form I'm trying to determine the best method to store each of one of the form items before all the data is sent to the server. I've looked at the following methods
Javascript arrays
XML document
Send each form item to the server side to be stored in a session
The good, the bad and the ugly
Depends on your application functionality and requirements, but Javascript would probably be the best way. You can use either arrays or objects or whatever in javascript. It's server independent and it will preserve data over a long period of time as long as client session stays present (browser window doesn't close for whatever reason) but this can be quite easily avoided (check my last paragraph).
Using XML documents would be the worst solution because XML is not as well supported on the client side as you might think.
Server side sessions are good and bad. They are fine if you store intermediate results from time to time, so if client session ends because of whatever reason, user doesn't loose all data. But the problem is that it may as well expire on the server.
If I was you, I'd use Javascript storage and if needed occasionally send JSON serialized results to server and persist them there as well (based on business process storig this data somewhere else than session could be a better solution). I'd do the second part (with sever side combination) only if I would know that user will most probably build forms in multiple stages over a longer period of time and multiple client sessions. but can be used for failure preventions as well. Anyway. Javascript is your best bet with possible server-side interaction.
Preserving data between pages on the client
Be aware that it's also possible to preseve data between pages on the client side. Check sessvars library for this. So even if the page gets refreshed or redirected and then returned all this can be stored on the client side between these events like magic. Marvelous any rather tiny library that made my life several times. And lessened application complexity considerably that would otherwise have to be implemented with something more complex.
I used TaffyDB to store data, and it's just wonderfully easy to implement.
Hope this helps you
You may want to check out PersistJS, which exposes a cross-browser persistent storage object. Of course, being persistent, data stored with this library survives sessions, not just page changes.
The latest version (0.2.0) is here – note the version in the above linked post is 0.1.0.
A combination of #1 (although I'd use objects, not arrays necessarily) and #3 would seem like a good approach. Storing the data locally in the browser (#1) makes it immediately accessible. Backing that up with session-based server-side storage defends you from the page being refreshed; you can magically restore the page just as it was.
For my web application, I need to store form inputs spanning across multiple pages, until I finally process/manipulate them to produce some results (its mostly formatting the data entered and presenting it in some layout). The options I think I have are -
Keep sending user's inputs to the server, store it there in some database, do the final manipulation there only, and show the result.
Store the inputs in browser's storage as the user fills the forms, and finally use this stored data to manipulate and show results.
I very much want to use the second method, and perhaps a possible way is using cookies, but I'm afraid I might just hit some upper limit of cookie data storage. I'm also open to understanding the merits of the first method, or any third method.
thanks.
Use webstorage (you can client-side store around 5MB of text or binary data)
Firefox demo: http://codebase.es/test/webstorage.html
DOM Storage is supported in these web browsers:
Internet Explorer 8
Firefox 2 for sessionStorage, 3.5 for localStorage
Safari 4
Just google for sessionStorage and localStorage objects.
Also modern webkit browsers supports client-side sql.
Edit:
I'm not sure about what you want to do but using AJAX you can store everything in javascript variables and serverside databases or sessions are a good choice.
Hitting the storage limit of the cookie could indicate you are trying to store too much on the client side. It might be prudent to store it serverside, in something like a session. The key to the session could then be stored in a cookie.
An alternative method is to not have the requests span multiple pages, and just store the data on the client side, not as a cookie, but as different form fields and/or text fields (they could be hidden). The merit of such a method is it doesnt hit the cookie limit as you have. It also makes your serverside code easier/cleaner, since it doesn't have to keep track of state (something you'd always have to do if spanning across pages, and thus the reason you are hitting the cookie limit in the first place).
You could use a small Flash Movie to store some data via Flash's Shared Memory Api or have a look at Google Gears.
Maybe also consider, that every byte you store in the cookie have to be transmitted everytime you website makes a request to the server.
Generally cookies have a max size of 4k so you could store quite a bit of data in there.
Be careful with validating all information that lives cookies - all the information resides on a client browser and can easily be manipulated by users of the site at any time.
You didn't say which platform you use. Spring Webflow does exactly the kind of form processing that you want:
http://www.springsource.org/webflow
Even if you don't use Java you could use some of the principles.
Edit: One more drawback of big/complex persistent cookies is that you have to make sure that any new code you deploy is backwards compatible with all the cookies that are out in the wild.
I would suggest storing the data in a session variable until you get to the final step rather than a cookie. I think this would be safer for your data as the user does not have direct access to the data, so you can validate as you go.