Form data to object

[TomTees]

Sorry if I asked this before in some variant, but I had to put my OOP studies aside for a few weeks, so here I go again?!

 

I am trying to learn OOP and would like to take the data submitted in a form and put it into an object so I can pass that to other objects and do stuff with said data in OOP terms.

 

My *limited* understanding of things so far is this...

 

If I have form "registration.php", when the user clicks 'Submit' then data from the form gets populated immediately in the $_POST array and control would go to the action page...

 

I would like to take

 

- email

- password

- name

 

into a generic object called FormHandler.  (Maybe this isn't how the OOP gurus would do it, but hmor me as I am trying to learn elementary OOP, and use something that works for me.) 

 

So how would I go about doing that?

 

All I can think is to have an action page called "form_handler.php" and when the user submits the form in "registration.php" then "form_handler.php" would instantiate FormHandler which would assign the $_POST array into either its own array or into individual variables.

 

Maybe something like...

 

class FormHandler{
private $someArray();

// OR

private $email;
private $password;
private $name;

function __construct() {
	$this->someArray = $_POST();

	// OR

	$this->email = $_POST['email'];
	$this->password = $_POST['password'];
	$this->name = $_POST['name'];
}
}

 

 

Feel free to tell me what you think of my code and idea, and please be nice because I have never written any OOP before and it is hard to break my old procedural ways!  :-\

 

 

 

TomTees

 

[trq]

I replied in your old thread saying that a simple wrapper around the $_POST array doesn't really *do* anything. You shouldn't just put everything into objects for the hell of it, objects need to do something useful / provide some functionality.

 

The code you have posted, while wrapping a specific set of data sent via a POST request, doesn't give you any benefit, and in fact would need to be edited if ever you wanted your user to be able to submit there age for example. OOP is not about editing your objects every time you need to make a change.

 

I would be more inclined to develop a Request object. This Request object would wrap around *all* data contained within the users request. This is generally what most frameworks do and while it alone doesn't really provide any extra functionality or benefit, it does now mean that all your request data will be within one object instead of a series of arrays ($_POST, $_GET, $_REQUEST, $_SERVER etc etc).

 

However, I'm still not real sure what exactly your trying to do. As I said earlier, putting everything in classes does not necessarily mean its OOP and OOP is not simply jamming everything in classes for the fun of it.

[ignace]

It isn't so complex, your really making this way harder then it should be. On the bright side your FormHandler is going the right way except it should be a base class/interface of some sort.

 

When we look at a form we see that it either maps indirectly to a table or maps indirectly to multiple tables. The first case is simple and an ActiveRecord would suffice. The second case is more difficult as you want a single entry point which communicates with many sub-system components/models. So IMO the second case would be better suited with the Facade pattern.

[TomTees]

I replied in your old thread saying that a simple wrapper around the $_POST array doesn't really *do* anything.

 

Sorry, I have been traveling and couldn't find the old thread plus I forgot that you said that.

 

 

You shouldn't just put everything into objects for the hell of it, objects need to do something useful / provide some functionality.

 

I was just trying to reduce procedural code.

 

 

The code you have posted, while wrapping a specific set of data sent via a POST request, doesn't give you any benefit, and in fact would need to be edited if ever you wanted your user to be able to submit there age for example. OOP is not about editing your objects every time you need to make a change.

 

That's why I'm here for help!  Because I obviously don't understand OOP very well yet.  (And all of those textbook 'Hello World' examples are useless.)

 

 

I would be more inclined to develop a Request object. This Request object would wrap around *all* data contained within the users request.

 

You lost me here.

 

The first thing I am trying to build is a simple Registration page/module.

 

The person is requesting anything.

 

 

This is generally what most frameworks do and while it alone doesn't really provide any extra functionality or benefit, it does now mean that all your request data will be within one object instead of a series of arrays ($_POST, $_GET, $_REQUEST, $_SERVER etc etc).

 

However, I'm still not real sure what exactly your trying to do. As I said earlier, putting everything in classes does not necessarily mean its OOP and OOP is not simply jamming everything in classes for the fun of it.

 

Okay, so let me dive a little deeper and explain what I am trying to do...

 

I am trying to build an e-commerce site and I want to do it using PHP and OOP.  (And no, I do NOT want to use a framework at this point.  This topic has been beaten to death by many a kind soul.)

 

My whole life I've been stuck doing procedural code and I've never been able to go from DuckSimulation and HelloWorld class examples in textbooks to something real-world like an e-commerce site.

 

While I don't know OOP, it is painfully obvious that most examples and people online don't really understand OOA, OOD, OOP and Design Patterns because there is a lot of dumping procedural code into classes - as you mentioned above - for the sake of it and really no planning into abstracting real-world things into logical OO designs.

 

It is not my goal to become a Gang-of-Four Fellow the first go 'round, however, I would like to write *reasonably* well laid out classes.

 

So...

 

My first goal is to build a simple User Registration module.  The flow would go like this...

 

- User enters Email

- User re-enters Email

- User enters Password

- User re-enters Password

- User enters Name

- User submits Registration Form

 

- System ensures valid Email

- System ensures Emails match

- System ensures valid Password

- System ensures Passwords match

- System ensures valid Name

- System ensures Email is unique

 

- System create new User account/record

- System notifies User of outcome

 

...from here the User would need to Log-In which leads to my next mini-project ---> build a Log-In module (using OOP)! 

 

I will need a "User" class and after discussing this topic with several people I trust, having a "RegistrationService" class seems wise.

 

I just figured that taking the User's form values and placing them in a "FormHandler" object which could inturn be passed to my "RegistrationService" object would be a nice OOP way to do things?! 

 

Hope that help describe more of what I'm trying to do?

 

Sincerely,

 

 

TomTees