On 17/06/12 22:28, nev young wrote:
On 17/06/12 12:45, Srdjan Todorovic wrote:
On 17 June 2012 12:23, Chris Greencl@isbd.net wrote:
requests it and the client fills in the form. The trouble is that there's no direct way for the PHP script that created the form to get the result - at least there isn't in any of the environment/frameworks that I've used.
Back in the day when everyone generally thought PHP was a good language to do web development in, I played about a little with PHP.
I agree with Srdjan, can be very dirty and nasty. Not least by the fact the user can tweak the data while it's at their end.
I agree with you both about the method, but don't understand why it's "very dirty and nasty". Of-course you can use (or build) a framework around it but no matter what language you're working with, fundamentally this is the nature of web programming over http. It's not that unusual generally in server/client programming in fact; the client generally asks the questions, the server answers them. So when you want the server to ask a question it has to be done in the form of answering a question with another question, and hoping that the next "question" includes the answer somehow.
Maybe an example of what Chris is tying to do would help. But in a simple case such as editing an item in a database (and without using any frameworks etc) I don't see the problem with having a script called "edititem.php" that first looks to see if there is data in $_POST (in which case process it), otherwise displays a form. Indeed, given that part of the job of the script will be to validate the data in $_POST, doing it this way means that if the data isn't valid you just go on to display the form again anyway, probably pre-filled with the form data from last time and adding in error messages.
Mark