Current Development Stages:
Stage 6 - Form Submission with RegEx Validation: Late-January 2020
The last stage captured information from our user to send to Marco.
IHow do we make sure Marco gets meaningful information?
By using form validation via regular expressions, of course!
Regular Expressions can act as filters to make sure a user provides valid input in a valid format.
See how it's done in this stage!
Stage 5 - Self-Referential Form Submission via the POST method: Mid-January 2020
Submitting information via POST is more secure since your information is not hanging 'out there' in the URL.
In this stage we examine the concept of a 'self-referential' page.
Huh? What is a self-referential page?!
Previous stages in our saga had a page that submitted or 'sent' information, and a separate page that 'received' or 'caught' the information. It was the 'action' attribute that told the sender who the receiver was.
A self-referential page provides 'one-stop-shopping' for a form submission process. The same web page sends and receives the information, and loads and/or processes things appropriately as the user interacts with the page.
Study this stage carefully...there are lots of moving parts!
Stage 4 - Form Anatomy and POST methods: Early January 2020
Do you GET what we have said so far about submitting forms via GET methods?
That transmission method can be useful in some circumstances, but it leaves wide open the possibility of users tampering with submitted information: even bookmarking pages with data in the URL!
If you look back at Stage 2 where we explored form anatomy, you see the form attribute: method = "GET"
Well, there's a new sheriff in town!
Introducing the POST method and $_POST super global array!
Using the POST method, information submitted in a form is stored in the $_POST super global array, but that info is not visible to the user in either the URL or anywhere else. This is a more secure form of submission, and therefore preferred in our humble opinion.
BUT...
Did you see how we used GET in the hyperlink to Stage 2?! Examine it carefully and watch what happens when it is used. When you link to Stage 2, a variable called 'openDetails' is used to open the drop-down detail sections in Stage 2, using the magic of PHP! This way, if a user wishes to view the form, they go there directly without any hassle.
This demonstrates a common, reasonable use of 'GET' when navigating between pages and triggering particular events related to how a page is displayed.
However...
This app is all about POST so open the app, examine the form in the source code and watch it perform - POST HASTE!
Stage 3a - Error Trapping Tweaks for Stage 3: Early January 2020
If you played around with Stage 3, you learned you could adjust user input by changing submitted variable values in the URL.
WELL....
We discovered another problem: what if someone changed the variable name (aka identifier)?! In Stage 3, it caused an awkward problem: a geeky 'Notice' of an undefined variable that was only apparent when we ran the app from our 'localhost' sandbox.
When the app was run from our live server, at TNT, the 'Notice' went away but the output was still a little misleading.
The reason for the discrepancy is that in live conditions, you can indicate how the PHP genie processes and displays 'Notices'...they can be supressed (and probably should be to prevent our guests from having heart palpitations!)
In development, 'notices' should be enabled so you cah catch errors before they occur.
While a 'notice' is not as bad as a 'fatal error,' or even a warning, we want them eradicated.
How did we eradicate the 'notice'? ! Open the app to see how we did it!
Note: in our defense: What if someone goes to the 'processing' page without going through the 'form submission' page? We should always allow for that scenario and it's easy to do: Just delete everything in the URL after and including the ? that separates the list of variables from the web page address. We did think of that, and here's what happens if you supply nothing for the GET to get.
The solution to the 'tweaked' identifier problem mimics the solution we used for no input at all.
Stage 3 - Array-Based Select Menus via Functions in PHP and GET method of Form Transmission: Mid December 2019
We can automate certain tedious operations via function with PHP.
Making a drop-down menu is one such nasty task, but we can automate it with a function in PHP and then harness its power anytime we like if we put it in, say, a utility library!
Once again you can bypass the form submission and go directly to the page that was supposed to capture the information sent from the select menu. What happens? Try it and find out!
Stage 2 - Forms and GET methods: Mid December 2019
PHP provides a collection of 'superglobal' arrays which can store information according to certain purposes or classifications. You can learn more at W3Schools, but for now, our focus is on how to send information in a form to another location...in this case, to another page in our ecosystem. We will use the superglobal array 'GET' to do so. This is going to GET interesting....
For grins and giggles, bypass the form submission and go directly to the page that was supposed to capture the information. What happens? Try it and find out!
Stage 1 - Iteration Loops in the 'Cave of Wonders': Mid December 2019
PHP is a language much like others. You can create variables, made decisions and do 'loopy' behaviors. This app shows off repetitive behavior.
Stage 0 - Intro to the 'Cave of Wonders': Mid December 2019
A place to start. We can write HTML5 dynamically using the server-side language, PHP. In this stage, we simply write an 'h2' 'Hello, World!' heading using the 'echo' command in PHP.
