Web Analytics Made Easy -
StatCounter Save form settings -- No Submit?? - CodingForum


No announcement yet.

Save form settings -- No Submit??

  • Filter
  • Time
  • Show
Clear All
new posts

  • Save form settings -- No Submit??

    I'm hoping this is obvious and I'm just missing it. I have a complex html form of roughly 18 printed pages and 1200 fields for creating a home inspection report, however only a dozen or so of these fields ever post to the database (order no. first/last name invoice data) while the rest (report data for a given home) are merely printed and saved to pdf with the customer record. There is no reason to create additional tables for the 1100 odd -- mostly blank --fields in the database, as once the report is printed and delivered to the client, we never need access that data again beyond reviewing the report from pdf, and that -- RARELY.

    The problem I'm facing is how to temporarily save the form -- partially completed -- that I may leave/exit (say the battery dies in my laptop) and then return to it -- partially completed -- to continue filling the report. Once completed, the final submit would (as it does now) rename Untitled.pdf to ThisRecord_Id.pdf, and then would delete our hypothetical temporary form.html. I suppose I would have to write an if else statement in the utility's load.php indicating if Record_temp_form.html exists, load it else load blank form, but I'm primarily interested in how to go about saving/creating the partially completed Record_temp_form.html
    Is this just crazy? Is my thinking on this ALL WRONG?

  • #2
    Assuming this webpage requires a username login type of deal, you could simply use a database table to store data that is not "finalized". Store the user ID along with some sort of inspection ID, and once that final SAVE action happens that pops all the data onto the PDF, delete the temporary data. Or you can use a text file to accomplish the same thing.

    With so many fields, your best bet would be to use a key/value system of temporarily storing the data and store only those fields that contain values (rather than having a 1200 column table ).


    • #3
      Thanks Fumigator.

      Could you expound a little on your key/value and text files suggestions?


      • #4
        What about cookies? I guess there's too much data for them actually...


        • #5
          None of the 1200 fields in question are assigned any value(i'm thinking of checkboxes in particular) so first it seems I would have to add values type="checkbox" value="1") to each form field, and then (I could be wrong on this) but then write some sort of code that says if value"1" (from our temporary key/value table) then the checkbox (preumedly of a specific id) is checked? At least that's the way it works for all the other forms in our SugarCRM based Home Inspection app.


          • #6
            Yes, you would need to give the checkboxes a value and then see if it's set.

            How did you know if a checkbox was set when you converted the form to PDF if they didn't have values?
            Learn CSS. | SSI | PHP includes | X/HTML Validator | CSS validator | Dynamic Site Solutions
            Java != JavaScript && JScript != JavaScript
            Design/program for Firefox (and/or Opera), apply fixes for IE, not the other way around.


            • #7
              Originally posted by mark87 View Post
              What about cookies? I guess there's too much data for them actually...
              Thanks mark87,

              Actually, as we were ramping up to this little project I fully expected to utilize cookies (though I still know next to nothing about them) but quickly learned that - Yes there is -- in fact -- far too much data to make cookies a viable solution. The save to pdf solution seemed obvious, right-up-untill our inspectors accidentally hit the back button or their batteries started to die, or they tried tabbing out of the inspecitions module (mid inspection) to enter an order in the orders module -- (talk about some T'd-off Inspectors!!)


              • #8
                It does sound like you need multi-page form input with temporary saving in between each page. It's no trivial task but your users will love you.

                The key/value thing would look something like:

                inspector_id int       //unique ID of the user
                inspection_id int       //unique ID of the current inspection (to allow for multiple inspections saved for each user)
                item_key char 30     //unique key (short descriptive text string)
                item_value char 120    //value for that key
                One real advantage to this design is you only need to store those keys that are actually used. If only 10% of the form fields typically get filled in, then storage requirements are only 10% of possible storage needed.

                If you have a lot of data that repeats itself, such as 10 text fields for up to 10 possible bathroom descriptions, you could also add a field "key_occurance" and increment the number, so you'd have a key "bathroom_description" and then the occurance field would store 0 through 9, rather than having 10 different keys (bathroom_description1, bathroom_description2, etc).

                You may also choose to have a field to store the page number of the form that key is used on, so you could limit your query to "select item_value from keyvalue_table where page_number = 2", which would give you all the info needed to load up page 2 of your form. That does make the whole thing less flexible though... if you decide you need to redesign pages of the form, your data will require updating to match. That could get messy! Normalization of that concept would mean you have yet another table that stores the relationship between each key and the page it's found on, and maybe even a sort order field (if that were useful).


                • #9
                  Originally posted by Kravvitz View Post
                  Yes, you would need to give the checkboxes a value and then see if it's set.

                  How did you know if a checkbox was set when you converted the form to PDF if they didn't have values?
                  Thanks Kravits,
                  So, add to that all dropdown and combo-box options and we're talking about one heck of a bunch of work here???

                  The PDF "conversion" is merely a matter of printing the html form to a pdf. We use "Click_to_convert" which is established as the default printer.


                  • #10
                    Thanks Fumigator et.al.
                    I can see the writing on the virutal wall. "I think "no trivial task" understates things quite a bit. A ton of work, is more like it. Wondering about possibilties in creating the form as editable pdf to begin with, but not sure about possibilites for combo-dropdown-text boxes (choose boilerplate options or enter own description etc) and interfacing with mysql db.


                    • #11
                      Here's a thought (and I should probably move this to the php forum but...) wouldn't it be possible to dynamically generate our hypothetical temp table via php, applying logic to the submit that says (and I won't even guess at syntax here but...) something like:

                      if not exists, table named "temp_report"  
                      CREATE temp_report;
                      for each myform.field.id like"regexp" not empty 
                      ALTER TABLE  temp_report ADD COLUMN "regexp"
                      1. Does this make sense?
                      2. If so, would it help my cause or just turn into a blind alley resulting in just as much work in the long run?