too many form inputs?

[garyed]

I'm working on an online php program that can have a few hundred form inputs. Mainly just numbers  from 1 to 50,000 depending on the field. I wanted to use cookies so the user can keep the data entered on their browser but i found out the hard way that the browsers have a limitation that I've exceeded. Does anyone have any ideas?     

[requinix]

Well, just think about it. Can't use cookies. What else is there available for you to use?

[garyed]

I guess I can use sessions but I'm on a shared server & I don't know if it will be too much for my web hosting package.  Also the problem with sessions is the user loses everything once they close their browser. 

[requinix]

It would be a lot of data to store in a session, that's true. However it doesn't have to be lost when the browser closes - the cookie that supports sessions can be given a lifetime just like any other cookie.

But still, no sessions. What else do you have access to?

[garyed]

I guess I'm kinda stuck because all the things I need to do to make a session act similar to a cookie is going to put a lot more load on the server than I wanted to. I just don't know if I have any other options. I was hoping there was something I'm not aware of since i'm not very good at this stuff. I just learn as I go & I didn't even know that browsers had a limitation on cookies until after almost finishing my program. I do appreciate you telling me like it is, so I can get out of dreamland & face reality.

[requinix]

You said shared hosting. Does that include a database?

[garyed]

I guess so, I have a basic shared server hosting package that includes  (supposedly) unlimited mysql  databases. 

I have heard that if you use more than expected whether it be traffic or load on the databases, that most web hosts will make you go to a private server. 

[requinix]

"More than expected" is for people who strain the servers. You won't be doing that, right?

Store the inputs in a database table and have the data associated with the user. You haven't described anything more about your application or what those inputs are all about so it's hard to give more specific advice...

[kicken]

12 hours ago, garyed said:

I wanted to use cookies so the user can keep the data entered on their browser

Do you really want to keep the data in the users browser?  If you do, there are other options available that would allow that.  Keep in mind however that storing the info in the browser means it's only available in that browser instance.  So if someone input all that data on their home desktop PC, they would not be able to pull it up later on their laptop later for example.  The data would also be unavailable to you as the site owner.  Good for ones privacy, bad if you want to use the data in some way.

 

If you want it available from any browser/location then storing it on your server in a database is the best option.

[benanamen]

13 hours ago, garyed said:

an online php program that can have a few hundred form inputs.

In a single form? That sounds like quite a lot. What exactly do you have going on?

[garyed]

Why don't I just give you guys a link to my site so it will be a little clearer what i'm doing. It's a load calculation program for home Heating & AC systems. 

https://www.loadcalc.net

That site runs off a default 24 minute session & none of the data entered is anything I have any interest in at all.  Now imagine that instead of calculating one room , doing 15 or 20  rooms the same way.  That's what I'm working on.  It can take some time do a full load calculation & almost the same amount of data needs to be entered into every separate room. I think I'm going to try keeping sessions but set my session.gc_maxlifetime to a higher number & see how things work out.  

 

 

[requinix]

Is there any particular need to have every step on different pages? The first couple about location, sure, but after that, wouldn't it be easier to have everything at once? It also helps the user see just how much they'll have to do, instead of one more page after one more page after one more page...
If you need multiple pages, what about simulating multiple pages? Put everything into the one HTML response, then use Javascript to show/hide chunks of it as the user progresses.

On that note, is there a need for this to be PHP at all? Javascript is quite capable of doing math. You may be able to do all of this on the client side.

[kicken]

On the surface, this to me does look like a project that's best done with javascript in the style of a single-page application.  Once the page is loaded there would be little to no need for it to ever contact your server again as all the information and processing would be handled locally by the users client.  This way they can take as much time as they need, and potentially even work offline without an internet connection at all.

If you'd prefer to keep the project with PHP, say because you're not that proficient in JS but are in PHP, then what I would do is just keep the information in your form as a hidden input.  For example, when rendering the form on the second step you might do:

<input type="hidden" name="step1data" value="<?=htmlspecialchars(json_encode($_POST));?>">

Then when the form on step 2 is submitted you can pull the data from step one back into a PHP array by json_decoding $_POST['step1data'].   By passing the data around like this you make the application stateless from your server's point of view so there's no need to mess with sessions or timeouts at all.

 

[garyed]

3 hours ago, requinix said:

Is there any particular need to have every step on different pages? The first couple about location, sure, but after that, wouldn't it be easier to have everything at once? It also helps the user see just how much they'll have to do, instead of one more page after one more page after one more page...
If you need multiple pages, what about simulating multiple pages? Put everything into the one HTML response, then use Javascript to show/hide chunks of it as the user progresses.

On that note, is there a need for this to be PHP at all? Javascript is quite capable of doing math. You may be able to do all of this on the client side.

I started the project about seven years ago so I have been learning as i go. I may not have known how to put the state & cities on the same page at the time but that might be a good idea to cut it down to three pages instead of four.  I know i wanted the last page & the page before it on separate pages. I didn't want things to look cluttered. The last page is going to have up to 20 rooms instead of just the one you see, so I wouldn't want anything else on it.

[gizmola]

One other option available to you would be to use HTML 5 local storage.  This allows you to have the client save its data locally.  Since you would be well served to update your html from 4.01 to 5 anyways, it would be a great time to experiment with LocalStorage.  

The javascript API is incredibly simple:

localStorage.setItem('myCat', 'Tom');
const cat = localStorage.getItem('myCat');
localStorage.removeItem('myCat');
localStorage.clear(); //Clear all items

Quote

 started the project about seven years ago so I have been learning as i go. I may not have known how to put the state & cities on the same page at the time but that might be a good idea to cut it down to three pages instead of four.  I know i wanted the last page & the page before it on separate pages. I didn't want things to look cluttered. The last page is going to have up to 20 rooms instead of just the one you see, so I wouldn't want anything else on it.

Ajax is the answer.  When you have a cascading group of interconnected dropdowns, you want to convert your code to make ajax calls.  On the serverside it's pretty easy -- you just concentrate on the data.  So let's take zipcode to city/state as an example.  User is prompted for a zipcode, and you then lookup the city/state for that zipcode in your database and return those.  The client parses the city/state and updates those values in the user's form.

Lots of things have changed in the javascript world since you first implemented your app.  You want to move to the modern way of doing ajax calls, which is to use Fetch with promises.  The two go hand in hand, in that fetch was designed to use promises.  About this, I will just say that the hard part of ajax is what happens when there are errors.  People often concentrate on the "happy path" where everything works, and ignore the issues with the asynchronous web.  Fetch and promises help you write a more robust app with simpler code.

Here's a nice tutorial link, although there are many available if you need more help learning them.  For example, if video tutorials work for you, you can find many on youtube by searching for "javascript fetch".  One important fundamental is to return all your data from your php scripts in json format.  That makes it easier to integrate the results into your clientside code.

[garyed]

11 hours ago, gizmola said:

One other option available to you would be to use HTML 5 local storage.  This allows you to have the client save its data locally.  Since you would be well served to update your html from 4.01 to 5 anyways, it would be a great time to experiment with LocalStorage.  

The javascript API is incredibly simple:

localStorage.setItem('myCat', 'Tom');
const cat = localStorage.getItem('myCat');
localStorage.removeItem('myCat');
localStorage.clear(); //Clear all items

Ajax is the answer.  When you have a cascading group of interconnected dropdowns, you want to convert your code to make ajax calls.  On the serverside it's pretty easy -- you just concentrate on the data.  So let's take zipcode to city/state as an example.  User is prompted for a zipcode, and you then lookup the city/state for that zipcode in your database and return those.  The client parses the city/state and updates those values in the user's form.

Lots of things have changed in the javascript world since you first implemented your app.  You want to move to the modern way of doing ajax calls, which is to use Fetch with promises.  The two go hand in hand, in that fetch was designed to use promises.  About this, I will just say that the hard part of ajax is what happens when there are errors.  People often concentrate on the "happy path" where everything works, and ignore the issues with the asynchronous web.  Fetch and promises help you write a more robust app with simpler code.

Here's a nice tutorial link, although there are many available if you need more help learning them.  For example, if video tutorials work for you, you can find many on youtube by searching for "javascript fetch".  One important fundamental is to return all your data from your php scripts in json format.  That makes it easier to integrate the results into your clientside code.

Very interesting. That seems like something to look into but I do move at a pretty slow pace. I really do appreciate the ideas.