Hi Petre, I'm beginning to have second thoughts about my earlier idea too; coz that is not solving the actual problem (u're have a slow n/w). Afterall how many KB of form data is she/he actually sending? I'll think of other possible solutions.
Regards, -shiva "Petre Agenbag" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi Shiva > Appreciate your input. Wrt the spanning of the form, I think, in my > situation, it would actually make things worse... You see, my suspicion > is that most of the users who are experiencing problems, have very bad > connections, many complain that they lose connectivity while they are > busy with the form ( it takes them maybe 30 min or so to fill out the > entire form ( they basically transfer the data off paper forms they have > filled out earlier while "on-site", so it's not really alot of data, but > there are a lot of fields...) > So, my fear with this approach is that they will maybe get past the > first part of the form, submit that OK, then start getting trouble with > subsequent parts, leaving me with a whole lot of partial entries in the > DB., and how do I get them to "resume" at a a later stage? > You don't understand the mindset of these people, when something goes > wrong, they'll switch off their PC's and try to start from scratch, so > it's going to be difficult to try and get them to understand the concept > of multi-part forms... I shudder to even think what will happen, or > worse, how I will be able to allow them to make corrections on a certain > part of the form once they have submit it. And sometimes, to their > defense, it's not them that want to change the details on the form, but > the subject of the form who has decided to change their name etc... > > I'm not ditching this idea, I will definitely give it some more thought, > it's just at this moment, my mind is running through my original idea of > PDF forms trying to evaluate it. > > Each method will have it's pro's and cons, and I'll have to go and weigh > them. I must add, I don't see "effort" as a con for a particular > solution, as long as I know it will solve the problem without adding > other cons... > > Thanks again, will take it up with you again ( need some more input on > this PDF thing to get some balanced views) > > PS, if you have experience with using this method, I would appreciate it > if you could let me have your "field notes" and how successfull it's > working for you. > You see, the main thing here is that I need to KNOW when someone who > says they have submitted something actually have, and that they are not > trying their luck... > > > On Tue, 2003-07-01 at 13:43, Shivanischal A wrote: > > hi, > > > > seems u have complicated task on hand mate. cant u simply consider span the > > user input over multiple pages? i mean using 2 or more form on different > > pages instead of a single form on one single page. if this cant be done, > > we'll think of other measures. but this is by far the most simple method > > > > -shiva > > > > > > "Petre Agenbag" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > Hi List > > > > > > OK, firstly, sorry if this has been on the list before... > > > > > > What I'd like to do is something like this: > > > > > > I currently have an app that takes user input via a normal html form, > > > and then pops the content into mysql. > > > > > > The problem is that lots of user complain that the submit times out due > > > to slow/bad connections, and hence the data gets lost. > > > > > > What I was hoping to do now, was to somehow create a PDF form from the > > > current html form ( should generate itself on the fly ) , the PDF form > > > will obviously need to be downloaded to the user's PC, and will be > > > unique for each time they use the system, ie, I don't want to just give > > > them a blank template PDF, some of the values need to be > > > "auto-completed" and inserted into the form as "read-only", as well as a > > > couple of "hidden" fields with identifying values so I can know where to > > > pop it into the db. > > > > > > The idea is that the user will now come to the point where he would > > > usually have filled in the html form, but instead, the app must > > > autogenerate a PDF with some values auto-completed and/or hidden, and > > > the user then downloads the pdf to his/her PC, where they continue to > > > fill out the pdf form. > > > > > > Then, on completetion, I'd like to investigate several delivery > > > mechanisms, arguably, the easiest way for the users ( who are mostly > > > techno-peasants), is to simply e-mail the pdf as an attachment to me), > > > but then I will either have to create an auto-parser for the email > > > (prolly difficult and prone to problems with making sure the attachment > > > is correct etc), or I will have to then manually process the > > > attachments. > > > > > > Either way, I would need to "feed" the pdf to my app, where the > > > form/hidden variables would need to be harvested from the form, and noly > > > then (after validation), be entered into the db. > > > > > > So, simple concept, but I'm sure many pitfalls, the least being probably > > > that I have never done this, and don't know where to start, or even if > > > it's possible/advisable to follow this route. > > > > > > Hence my post here... > > > > > > > > > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
