From Form to Object

Tom_Tees

Still trying to get my hands around PHP OOP...

So let's say I have a Registration form called registration.php that looks like this...

Username:
Username (re-enter):
Password:
Password (re-enter):
Accept Terms Y/N:

Let's assume that I need to get the data from the form to a class called Registration that processes the information and registers the user. (We will assume that said class is the right way to process the data.)

So the question is, how do you get user data from a PHP form/page into a class so you can do something?

Do you need a helper class?

Is the PHP form page and the class one in the same?

Some other configuration?

If I was doing this in a procedural way, I would just have my HTML Form and PHP code intermingled and capture and handle everything in one .php file.

TomTees

bradgrafelman

I guess it would depend on your application, but if you had a User class, you'd probably supply some accessors and mutators to set the appropriate data, e.g.

$user = new User();
$user->setUsername($_POST['user']);
$user->setPassword($_POST['pass']);
// etc.

You could even get fancy with it and surround the mutators in a try/catch block so that your User class could throw exceptions if invalid data is passed (e.g. you call setUsername() with a blank username, or setPassword() with a weak password).

Tom Tees wrote:
Is the PHP form page and the class one in the same?

Not sure I understand what you mean by that. A class is like a blueprint of what an object can look like and/or do, and a form is just some HTML markup rendered by a browser. I would say that you're comparing apples to oranges, but it's really more like comparing apples to clothespins.

Tom_Tees

bradgrafelman;10954964 wrote:
I guess it would depend on your application, but if you had a User class, you'd probably supply some accessors and mutators to set the appropriate data, e.g.
$user = new User();
$user->setUsername($_POST['user']);
$user->setPassword($_POST['pass']);
// etc.
You could even get fancy with it and surround the mutators in a try/catch block so that your User class could throw exceptions if invalid data is passed (e.g. you call setUsername() with a blank username, or setPassword() with a weak password).

Not sure I understand what you mean by that. A class is like a blueprint of what an object can look like and/or do, and a form is just some HTML markup rendered by a browser. I would say that you're comparing apples to oranges, but it's really more like comparing apples to clothespins.

If I had a "registration form", in conventional terms, I would create a file called "registration.php" that would include HTML to create the page and form and PHP to handle the form submission.

If I am now trying to do this using OOP, my question was, "What files would I have?"

I have read that one class should be one .php file.

class Customer ---> customer.class.php
class Order ---> order.class.php

So if I'm taking an OOP approach, would I maybe have...

1.) A file consisting of HTML to display the form...

registration.php (includes HTML)

2.) A file that consists of a class to handle the actual registration...

registration.class.php

3.) A file that consists of a class that represents the Customer and maybe writes the data to the database...

customer.class.php

What I just described was something I used to see more which was called a "3-Tier Architecture" where there was a "Presentation Layer" (i.e. #1) which was the UI, a "Business Layer" (i.e. #2) which contained the business rules/logic/processing, and a "Data Layer" (i.e. #3) which took care of capturing the data and ultimately writing it to the back-end database.

Unfortunately this seems to be different from how the MVC model works?! :queasy:

At any rate, so I thought maybe having:

registration.php
registration.class.php
customer.class.php

would be a good way to do OOP for registering a Customer.

Make sense?!

TomTees

NogDog

Tom Tees;10954997 wrote:
...
Unfortunately this seems to be different from how the MVC model works?! :queasy:

At any rate, so I thought maybe having:

registration.php

registration.class.php

customer.class.php
...

But that, in effect, is MVC:

customer.class.php == model
registration.php == view
registration.class.php == controller (maybe overlapping a bit into model territory?*)

Personally, I suggest that if this is going to be a non-trivial application (for some undefined value of "trivial") that you consider using an existing framework upon which to build it. I personally like CodeIgniter, in large part because its documentation is so good, but there are many others to choose from, too.

Most definitions of MVC include the "business logic" in the model, yet most implementations of MVC frameworks tend to put a fair amount of "business logic" into controllers, so I guess all such theory is a guideline at best. 🆒

Tom_Tees

NogDog;10955016 wrote:
But that, in effect, is MVC:

customer.class.php == model

registration.php == view

registration.class.php == controller (maybe overlapping a bit into model territory?*)

Okay, so I made a small step forward. (Guess I need to really read up on MVC.)

Personally, I suggest that if this is going to be a non-trivial application (for some undefined value of "trivial") that you consider using an existing framework upon which to build it. I personally like CodeIgniter, in large part because its documentation is so good, but there are many others to choose from, too.

Thanks for the reminder. Yes, I should also check out CodeIgniter as well.

I just hate copying other people's code, since I almost never like the way other people code. (I'd never last on a coding team!!)

I also still feel "burned" by paying $65 for "Beginning PHP and MySQL E-Commerce: From Novice to Professional" and getting sucked into that author's loopy code and insistence on using SMARTY.

His "framework" just confused the hell out of me and made things way harder than need be.

But I guess that is life... Trying things on until you find the right match!!

* Most definitions of MVC include the "business logic" in the model, yet most implementations of MVC frameworks tend to put a fair amount of "business logic" into controllers, so I guess all such theory is a guideline at best. 🆒

Okay.

TomTees

NogDog

The thing about using something like CodeIgniter, CakePHP, Zend, etc. is that you normally don't edit (or even look at) any of the actual framework code, other than perhaps a config file or three. You write your own controllers or models, but do so by extending the base class for each in order to be able to implement the framework's code.

Check out the video tutorials in the link in my previous reply to see what I mean.