On Mon, Jun 18, 2012 at 10:31:31AM +0100, Mark Rogers wrote:
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.
Yes, I think you're right, this is probably the easiest way to do it.
What I'm currently trying to do is, as you say, adding/editing data to a database. However the database is irrelevant really as the sequence is something like:-
Get data out of database Show it somehow Ask user to add to or edit it Get user's data Put data back into database
It's the bits *between* getting the data out of the database and putting it back that I'm finding difficult/clumsy.
So a simpler sequence that simply asks for a response to a question and acts accordingly has the same communication problem:-
Ask user's favourite colour Get favourite colour Set text on page to favourite colour
It's quite complicated to do this from a web application:-
Code creates page with question about colour on it (in my case it's a Wiki page with a PHP plugin called to create the form).
User asks for the page from their browser which runs the Wiki code to create the page including my form plugin which creates the form.
When the user submits the form the form's action is run, this redisplays the page with the new colour (or if it's really clever just changes the colour without full redisplay).
So, by default, the code that 'asked the question' has no simple/natural way to get the user's answer. The form action function has to do something which the 'calling' code can see somehow.
I realise *why* this is so, the process/thread that sent the page has probably long gone by the time there is an answer sent back. However it does seem strange that there don't seem to be any frameworks for handling this in a more natural fashion.
E.g. it should be possible to have a high-level/parent process that both serves the pages (my Wiki software - called by apache) *and* collects the reply when the user sends it back such that one can run a conceptually single-threaded process to both ask the question and handle the reply with some sort of common environment etc.
As it is it's messy. My PHP plugin code doesn't really lend itself to being run as the form action because it depends on quite a lot of the environment etc. provided by the wiki generation, it can't easily be run stand-alone. Thus the form action has to be a separate stand-alone script of some sort that reloads the wiki page with some sort of parameter/data indicating the user's reply.