I agree with Don. If this was, say, an administrative page, sure (maybe). But, if it's anything the general public will be using, no way.
As for traffic, I guess it depends on the info that the form will be transmitting. If there aren't any textareas or file uploads, it's unlikely to amount to even a small portion of a single page download. Though upstream bandwidth is usually much lower than downstream, I don't think it's worth considering. The other thing, though, is your application will be opening many more DB connections. But, for the use you describe, I say don't bother. Do all your calculations when the user has *decidedly* submitted the data, not while she/he is working on it. If you're concerned about latency, throw up an animation or something on form submit. b On Thu, Nov 27, 2008 at 11:10 PM, hanther <[EMAIL PROTECTED]> wrote: > > This is an insurance quoting application, and we do allow partial > saving of the data, but a complete 'submit' is not allowed until all > edits have passed and required information has been entered. Our goal > is to provide instant premium updates and realtime edit checking based > on the information entered, so we are already using ajax to save some > things (deductibles, coverages and limits based on radio buttons) to > the database and doing a premium calculation and also returning edit > messages, but my concern is with the rest of the info - policy holder > details, loss payees, and a few other things, some of which can also > affect the premiums. For consistency it seems to me that it all > should save immediately but you're right in that it adds complication > and also increases the chance of a failure... > > > > On Nov 27, 6:33 pm, donb <[EMAIL PROTECTED]> wrote: > > Well, I wouldn't do it. I would not want to commit the data entry > > until it is all input - all none, atomicity is goodness. Countless > > times I have started filling out some form myself - realized I didn't > > want to go through with it for some reason or other and bailed out. > > If perchance one of the early values was my social security number, > > it's not so cool that it has already gone to the server even though I > > believe I've cancelled my form. > > > > There may well be validation issues that can't be resolved with only > > part of the form posted, too. > > > > The network/timeout issues are only magnified - 50 chances to fail vs > > one. Save the values in a cookie if need be, so they don't get lost > > if there's a failure. > > > > Better still, use an Ajax post technique to send the data. Trap any > > error from that and deal with it. Your form full of data will not > > have gone away, so you can recover easily from the error, perhaps > > completely unbeknownst to the user you could retry or resubmit to a > > backup server if the primary has gone dead. > > > > Don > > > > On Nov 27, 7:01 pm, hanther <[EMAIL PROTECTED]> wrote: > > > > > > > > > I'm thinking about adding the functionality to auto save the user's > > > data using ajax calls after each time he leaves a field and has > > > changed the data in it, but my concern is about the amount of traffic > > > and calls this will generate between the browser and the web server. > > > Should I be concerned about this type thing of this in this day and > > > age? > > > > > Overall, there aren't many fields - less than 50, but I can end up > > > with multiple rows of data within it, ex a list of names with their > > > related address, street, province/state, etc > > > > > Besides the obvious point of the user never losing any of his data due > > > to session timeout or network issues, another reason for me wanting to > > > do this is because the data entered in certain fields can affect other > > > fields, and generate errors and warnings that the user must address, > > > so I'm thinking this would be a nice way of 'instant notification' of > > > issues with the data > > > > > Anybody have any thoughts? > > > > > Thanks, > > > Cory- Hide quoted text - > > > > - Show quoted text -
