How frequently data should be saved if form is very large - javascript

I have a doubt on saving data in database using ajax. (I can do this part). My problem is I have a very large form which is nested( I can't change it). Large form in terms of input fields which need to be saved in data approx 100 fields. new field may open it depends on users selected options.
ex- suppose one question is like which game you play. In multi select drop down if he selects one game than next questions would be how frequently you play this game .on which day which time and many more. Each game may have different set of question.
Now my problem is how to save this data in database. Should I save it after user click submit or should I save it in between user is feeling data. so that he refresh the data it can have his data filled .
How frequently should I send Ajax request for saving data and how to get the data from the fields which are newly field and how I should save it in Rails.
I know about update.attributes
please help me or give some suggestions how should I do it.

If you live edit or only on save has mostly user expierence questions.
But if you are frequently saving (like an autosave) and are worried about the size (100 normal columns might be OK anyway, allthough large text or blobs less so) then what you want to do fairly simply is only save the fields that have actually changed.
There are many ways to implement this in JavaScript. You might just save each input when the user finishes editing it (e.g. the input loosing focus) or you might save based on a timer and track the changed fields since last save.
Then have your JavaScript just include those fields in its AJAX request (PATCH migh be a good method to use). Rails should then only try to save the attributes on the object that you changed (via update_attributes, or save on the ActiveRecord). If you want to also optimise out the SELECT, use update or update_all on the class. e.g. ends up like:
MyBigRecord.update(id, title: "My new title")
You can easily use the normal strong parameters here, which only includes those actually present in params.
MyBigRecord.update(id, params.require(:my_big_record).permit(:title, :author, :etc))
If you need to deal with sub objects then you may need some special handling, but the idea is the same). A little bit of logic can also do the initial create on demand, allthough your JavaScript then recieve the id to use for future saves.

Related

introduce a draft like functionality using javascript

I have a stand alone HTML form, and I want to add a functionality similar to a save as draft. If suppose the user fills up half form and decides to pause and continue filling form some time later . When the user visits the website again the previously filled data should be available to the user. In simple words I want to achieve something like save and complete the form later.
Also to add this is a stand alone HTML form using javascript. When I browsed on the net one suggestion I found was localStorage. But just want to know if there is some other way of achieving this functionality. Please direct me to some useful link which can help me with this feature.
If you act on the client you may use all the clientside persistent facilities currently available like local storage, websql, cookies.
I think that local storage is the easier to implement and you find a lot of libraries that provide you a friendly interface to interact with it like http://www.jstorage.info/ for jQuery or https://github.com/tymondesigns/angular-locker for AngularJS.
What you need to do is something like:
var frm = $(document.myform);
var inputs = frm.find('input');
inputs.change(function() {
var data = JSON.stringify(frm.serializeArray());
localStorage.setItem("form", data);
})
You can put a check for the existence of that key in local storage during the page load and then populate the form accordingly.
Hope it helps :)
There are only a few ways to do this. A completely portable implementation will require server-side changes.
localStorage - Save Form using localstorage HTML5
 Use Javascript to save the data which is entered into the form as it changes. I recommend implementing this layer no matter which version you decide to go with.
Save in database - Examples vary by back-end language.
 The simplest implementation of this is to add a single boolean column to your database which indicates all data necessary to continue has been collected. This version has the benefit of being usable across machines.
Cloud storage - http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-intro.html
 You might consider using a service like Amazon DynamoDB or another NoSQL cloud storage system to cache data like this. The convenience of sending a JSON object to most NoSQL engines and restoring the same to a form is great, and codes very similar to the localStorage version.
Q-Code / Code restoration - http://webqr.com/
 This, in my opinion, is the worst option. However, it may fit your scenario. Generate a Q-Code which the user can scan to restore the page with the data. Q-Codes can hold a surprising amount of data. If your form doesn't use much text entry, you might get away with giving the user a short code (5-8 characters) which can be used to restore the form state.

Passing additional information per input box using HTML

I'm asking this question since I'm simply not clear on where to research further - I have experience primarily with Python, while my HTML and Javascript knowledge are on an as-needed basis. I simply haven't been able to figure out the most elegant and standard way to do this, and which component (the HTML itself, a Javascript component, Django) should be responsible for doing what I want.
I am trying to create a form for input of linguistic data with a Django app. Important for what I'm doing here is that each datum has associated tags. Also, most linguistic data is paradigmatic, so I want to be able to have users input an entire paradigm at a time (rather than one single datum at a time, which can be done already using the Django admin interface). I also, ultimately, want to have the paradigmatic input be dynamic in the future, so that I do not have to hardcode things.
For example, I would like have a form that looks like the following:
On submit, I would like the page to send something like this to the server:
'I', tags:'singular, 1st'
'we', tags:'plural, 1st'
ˈYou',tags:'singular, 2nd,masculine'
...
I simply don't know what the best way is to embed this extra data into the website so that it gets submitted when the page gets submitted. Ideally, the input boxes could somehow 'inherit' the tags based on their position in the columns and rows rather than each input box needing to be have that information added individually.
The only idea I've had so far is to embed the tag information into the names of the input boxes so that the string passed on a get command would be something like '?singular_1st=I&plural_1st=we&singular_2nd_masculine=You' and I would just have to process the strings on the Django backend. I could also use javascript to assign the names of each of the textboxes on pageload somehow, though I'm not sure how to figure out which textbox is located where relative to the headers of the table.
What is the best way to do this? Can I somehow pass more structured data on submitting the page, rather than having to reparse everything on the backend? I've read something about passing JSON to the server, but I'm not sure how exactly to do this. Similarly, there's a data attribute in HTML 5, but I'm not sure how (or if) that gets passed to the server on submitting a page. I'm not asking for anyone to do my coding for me, but simply a suggestion about how best to do this and further resources or tutorials showing similar projects.

Call SQL "function" (stored procedure?) every time a database column is selected

I am running MySQL 5.6. I have a number of various "name" columns in the database (in various tables). These get imported every year by each customer as a CSV data dump. There are a number of places that these names are displayed throughout this website. The issue is, the names have almost no formatting (and to this point, no sanitization existed upon importation):
Phil Eaton, PHIL EATON, Phil EATON, etc.
Thus, the website sometimes look like a mess when these names are involved. There are a number of ways that I can think to do this, but none that are particularly appealing.
First, I can have a filter in Javascript. However, as I said, these names exist in a number of places throughout this (large) site. I may end up missing a page. The names do not exist already within nice "name"-classed divs/spans, etc.
Second, I could filter in PHP (the backend). This seems about as effective as doing it in Javascript. I could do it on the API, but there was still not a central method for pulling names from the database. So I could still miss an API call anyway.
Finally, the obvious "best" way is to sanitize the existing data in place for each name column. Then at the same time, immediately start sanitizing all names that get imported each time we add a customer. The issue with the first part of this is that there are hundreds of millions of rows of names in the database. Updating these could take a long amount of time and be disruptive to the clients' daily routines.
So, the most appealing way to correct this in the short-term is to invoke a function every time a column is selected. In this way I could "decorate" every name column with a formatting function so the names will appear uniform on the frontend. So ultimately, my question is: is it possible to invoke a specific function in SQL to format each row every time a specific column is selected? In other words, maybe can I call a stored procedure every time a column is selected? (Point being, I'm trying to keep the formatting in SQL to avoid the propagation of usage.)
In MySQL you can't trigger something on SELECT, but I have an idea (it's only an idea, now I don't have time to try it, sorry).
You probably can create a VIEW on this table, with the same structure, but with the stored procedure applied to the names fields, and select from this view in your PHP.
But it has two backdraw:
You have to modify all your SELECT statements in your PHPs.
The server will always call that procedure. Maybe you can store the formatted values, then check for it (cache them).
On the other hand I agree with HLGEM, I also suggest to format the data on import, because it's a very bad practice to import something you don't check into a DB (SQL Injections?). The batch tasking is also a good idea to clean up the mess.
I presume names are called frequently so invoking a sanitization function every time they are called could severely slow down your system. Further, you can't just do a simple setting to get this, you would have to change every buit of SQL code that is run that includes names.
Personally how I would handle it is to fix the imports so they put in a sanitized version for new names. It is a bad idea to directly put any data into a database without some sort of staging and clean up.
Then I would tackle the old names and fix them in batches in a nightly run that is scheduled when the fewest people are using the system. You would have to do some testing on dev to determine how big a batch you could run without interfering with other things the database is doing. The alrger the batch the sooner you would get through all the names, but even though this will take time, it is the surest method of getting the data cleaned up and over time the data will appear better to the users. If the design of your datbase allows you to identify which are the more active names (such as an is_active flag for a customer or am order in the last year), I would prioritize the update by that. Alternatively, you could clean up one client at a time starting with whichever one has noticed the problem and is driving this change.
Other answers before give some possible solutions. But, the short answer for the specific option you are asking is : No. There is no such thing called a
"Select Statement Trigger", that too for a single column, although triggers come close for this kind of expectation, but only for Insert, Update and Delete operations.

Auto populate word document fields with database info

I've been trying to set up a system where a user inputs data for a proposal, the data is saved to the database, then (when needed), the system will automatically place the data into tagged fields in a pre-made document. I have everything done as far as data entry is concerned, I just haven't been able to find any info on how to auto populate the tagged fields in the document itself.
This might not be exactly what you are looking for but it sounds like you want to use MS Word fields.
http://office.microsoft.com/en-ca/word-help/field-codes-in-word-HA010100426.aspx
Edit:
Sorry misread the question. You one option is to do a mail merge. In Word 2010 select the mailings tab then the start mail merge pull down and follow the wizard. Super easy way to pull DB info into individual documents and you can easily select which records you want printed/created.

Is it bad to store temporary data into hidden element? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
At one interview, once I attended, I was asked to create one java script based functionality in which I was said to create one form (say i.e first name, last name, email, age) and one listing(actually listing was kind of another form storing multiple entries) below this form. On submitting this form one new row was added to listing. However it is possible to remove any previously added listing row. and after adding removing, finally need to store this final state of listing. ( Kind of form post and server side scripting comes into picture )
So what I did that, On Form submit, adding a new <tr> row in listing table at the same time I serialized all form data except submit button using jQuery serialize and stored it in one hidden element of listing form.
On removing listing row, I was removing <tr> row along with respective hidden element for the same row.
All was working like great without any error. But the interviewer asked me that "The approach I used (hidden elements) was really proper?".
I replied, I could have used json?
but Could not crack interview.
So I want to know what is best approach that We can use to store data in such conditions?
Another approach for client-side is to keep a list of objects separately and only store the reference to each item inside a property of your DOM element. This approach is very similar to what jQuery's $.fn.data() provides and has these advantages:
You don't have to serialize anything, the data stays in its native format; it should be said that you could have achieved this by adding a property as well.
All your data is kept in one place instead of scattered around in the DOM.
This is an example implementation:
(function(ns) {
var entries = {},
entryId = 1;
ns.Entries = {
addEntry: function(data) {
entries[entryId] = data;
return entryId++;
},
getEntryById: function(id) {
return entries[id] || null;
}
};
}(this));
Calling Entries.addEntry returns an identifier that you can store in one of the DOM element's properties:
tr.entryId = Entries.addEntry(data);
Later you can use that entryId property to find the corresponding data in the entry list and use it.
var data = Entries.getEntryById(tr.entryId);
Demo
Of course, this particular functionality can also be solved server-side by using sessions.
Thanks to HTML5, we now have the ability to embed custom data attributes on all HTML elements. These new custom data attributes consist of two parts:
Attribute Name
The data attribute name must be at least one character long and must be prefixed with 'data-'. It should not contain any uppercase letters.
Attribute Value
The attribute value can be any string.
Using this syntax, we can add application data to our markup as shown below:
<ul id="vegetable-seeds">
<li data-spacing="10cm" data-sowing-time="March to June">Carrots</li>
<li data-spacing="30cm" data-sowing-time="February to March">Celery</li>
<li data-spacing="3cm" data-sowing-time="March to September">Radishes</li>
</ul>
We can now use this stored data in our site’s JavaScript to create a richer, more engaging user experience. Imagine that when a user clicks on a vegetable a new layer opens up in the browser displaying the additional seed spacing and sowing instructions. Thanks to the data- attributes we’ve added to our <li> elements, we can now display this information instantly without having to worry about making any Ajax calls and without having to make any server-side database queries.
source: HTML5 Doctor
There are other methods too I believe.
Actually instead of using hidden elements , you can add data to the html elements using jQuery. This is a better approach to make your data a little less obvious/direct to the users. Check the data() in jQuery.
Nothing wrong with storing data client-side if the user can be trusted with it and nothing terrible happens to your system when he messes with it.
Only problem I can see with using hidden fields (or cookies) is that they get sent with every request, which might waste bandwidth. Not sure if that applies to your case, probably not, because you say you just submit once when all is done.
The problem with solutions that 'just work' is that they are not abstract enough and therefore tend to cause problems in the future. Consider your example; should you decide to store the temporary data in Local Storage (to allow users close their browser and return to it later), you'd have to rewrite how you store your data. If you stored it in a variable, you'd be able to add 'Save to Local Storage' just as easily as 'Submit to server' or 'Pass to Any Other Function' functionality. Your 'hidden element' approach would have to be rewritten for any purpose except posting to service.
To start with, multiple forms on one page are wrong - it's data loss antipattern. The correct approach would be to place everything into one form. This way, it would work even without JS and you could use JS only to improve usability, not to provide basic functionality. This solution would degrade gracefully an it would be easy to debug and maintain.
Of course, saving the data in hidden field is a valid technique.
By writing submitted data into the form itself, and reading again from it, you've tied these two elements together - they are said to be tightly coupled.
What word happen if another requirement came through to displaye previously submitted data in the table also? Or to put the form on a separate page?
If you take a more MVC approach, you can separate out the logic for the various parts - reading, writing and sending data. For example, as you said, writing and reading from a JSON model. This would make each aspect more readily extensible in the future.
I will not answer your question directly but will focus on interview and method you chose.
I would say you chose wrong way and well known IT company you applied this solution for can have problems.
You chose the way to store everything on client's side, but you shouldn't! As your client can lose a lot of data this way, because imagine the case when your listing form will never be sent? User will just forget to hit send (never trust user!). Then you lose everything... whole progress of your work... and let's say you've already added 50 listing items...
Also adding items like this can easily make your session expired (no requests to the server) and no data will be saved, because user will have to log in again. And you will have to handle it as well, or you will lose everything!
Sorry for exclamation marks, but I think data is crucial (especially for your client) so do not ever offer solutions which can make client losing it somehow.
So:
It's not bad to store data in HTML elements, but you need to apply this solution very carefully.

Categories

Resources