Posted by David Haynes on 11/19/23 11:46

stathis gotsis wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:85OdnbH4AKRfScnZRVn-pQ@comcast.com...
>> stathis gotsis wrote:
>>> Hello everyone,
>>>
>>> I am tying to come up with an elegant way to process some input data
> that
>>> come from a form. When the user hits the 'Submit' button, i want the
> form to
>>> appear again with the already entered valid data filled in and prompt
> the
>>> user to re-enter the non-valid data. If all data is valid, i will
> forward to
>>> an other .php page which enters the data into a database.
>>>
>>> I tried to do this in the following way: the form always hits back on
>>> itself, but when all data is valid i use the PHP:header() to redirect to
> the
>>> data.php that performs the database insertion. The problem is that the
> data
>>> is not available to data.php in the $_POST variable. How can i overcome
> this
>>> problem? Any other subtle way to handle the whole thing? Any help
>>> appreciated.
>>>
>>>
>> Stathis,
>>
>> I do things the same way you do - the page validates its own input and
> then uses
>> header() to move to the next page. But before the header() call, I store
> the
>> data in the $_SESSION variable.
>>
>> I prefer validating the data in the same page that contains the data. It
> keeps
>> the code together and, IMHO, cleaner. Plus, if it isn't needed in the
> next
>> page, you don't even have to touch that page.
>>
>
> Thank you for your answer. I missed the obvious: passing data through the
> SESSION object on to the next page. This solution might even be more concise
> than the MVC architecture that David suggested earlier on.
>
>
It is more concise but suffers from marrying the view to the business
logic. If you want to update the view, say for supporting cell phones or
separating web page creation from the business logic, then it is easier
under MVC than in a monolithic form.

Both work. Which is best for you depends upon your needs.

One thing I like about MVC is that the controllers and view all follow
the same general format which makes understanding a new page easier.

Controllers condition their environment, handle any POST/GET data, set
the SESSION and redirect.

Views bring in any SESSION data, set up for internationalization and
paint the form.

Obviously, you can combine the controller and view into one page. I find
that the resulting pages can get to be quite large (lines of code) and
complex (lots of business logic) which gets in the way on understanding
how the page is being defined (i.e. the HTML)

-david-

[Back to original message]