Hi Why don't you take the form in many smaller parts, save them away as each part is completed, allowing the user to go back and forth between the parts. This would give the advantage of securing the data which as already been submitted.
You can then give other functions to review in one page (for printing off) or copying to another form which could be used for next years data Regards Adam White -----Original Message----- From: Petre Agenbag [mailto:[EMAIL PROTECTED]] Sent: 28 January 2003 20:17 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP] best way to save form data on user side Hi Chris On Tue, 2003-01-28 at 22:09, Chris Shiflett wrote: > --- Petre Agenbag <[EMAIL PROTECTED]> wrote: > > I have a rather annoying problem regarding forms. > > I have built an app that allows the users to fill > > in a rather large form (much like a claim form) > > and then have the data pumped into a mysql db. > > The problem is: the users want to be able to > > "save" their forms on their systems as a) > > backup/proof that they have filled it in and b) > > for their records for future use and c) the hope > > is that it would also allow for a reliable method > > to complete the form off-line and then submit it > > when online again. > > Well, this sounds like a bad idea in general, but if you > have no choice in the matter, I suppose cookies can fulfill > the need. > > Anything you implement like this is going to lessen the > security of the data, because rather than the client > sending it to you once, you are going to expose it over the > Internet several times. If this risk is acceptable for > whatever reason, then cookies are probably no less secure > for this data than anything else. > > Normally, I would highly recommend *not* storing client > data on cookies, because that opens you up to several types > of attacks, but you can accomplish what you want to do with > this method. Only "punish" those who want this feature by > setting these cookies only for those who choose to save > this data locally. You could help the situation by > encrypting the data in your cookies, so that only > presentation attacks are a concern, but your users wouldn't > be able to easily look at their data as verification of > anything. > > My recommendation is to leverage your position as the > technical expert to advise a more proper solution, one that > you agree to, not them. They should not be consulted > regarding application design unless they have experience > with it. Rather, they should be describing their needs and > let you (or the technical lead / project manager) do the > technical design. This is exactly what I'm looking to do; but my problem remains: I don't know what the best solution is. The problem is clear: the users actually need an electronic copy of the data they submit; they must revisit certain issues annually, and would need to access the data they submitted the previous year; either for review purposes, or to make the new submission a speedy matter of simply changing the details that are different from last year. It's much like a normal office scenario: each person works on Word docs that need to be shared with others, yet needs to be editable and must be saved etc, BUT the difference here is that the data of all the collective sources must be entered into a central db. So the "non technical" solution would be for the users to do the forms in "word", then fax it to the central office, where you have a temp type the data into the db... we can't have that now... Any ideas? PS, I don't think cookies are going to do this. Remember, the user needs to be able to access and re-submit the form at any stage. > > Good luck to you. > > Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
