Newbie needs help using OOP

DoubleDee

Hi everyone. My name is Debbie and I am new to PHP Builder. This is my first time posting here so please be gentle with me! :o

I am trying to learn object-oriented programming along with learning more about PHP.

It seems like it is all the rage, and supposedly better than spaghetti coding.

I have a decent programming background but have never really understood OOP, and it is hard to go from "Hello World" examples in a book to building a real website using OOP.

To test my skills, I would like to build a simple Comments Page where visitors can type in comments about the website. My goal is to attempt to take the data from the form and immediately store it in an object. (If I want to use OOP, I guess it is better to do it whole-hog, right?!) :p

I have been playing around with some code, but I'm not sure it is even close to being right and I could use some help here.

Attached is the code I have so far for my Comments form and trying to turn the form values into an object...

Sincerely,

Debbie

NogDog

I would suggest starting by figuring out what aspects of the current project make sense to you to be defined as "objects". A given object should be as narrowly focused as feasible while still being able to stand alone as a conceptual "thing" that has its own set of properties and methods. You might, in your case, have a "Comment" object, for which you would want to decide what class variables are needed to define it, what public methods it would need for the main script to call in order to do things with it, and what private/protected methods it might need in order to help those public methods do those things.

Also, typically a developer will code each class definition in its own file (often, but not always, in a separate directory or directory tree for classes and with a standardized file naming convention) in order to make it easy to load that class as/when needed by any client code, possibly via an [man]__autoload/man function or via [man]require_once/man.

Anyway, the goal should be that you can build -- and test -- each class more or less independently of all the other code, then start instantiating and using them as needed within the main script (or higher level classes/objects) to build your application.

For some additional reading material, I suggest taking a look at: http://www.charles-reace.com/blog/2009/10/27/beginners-corner-learning-object-oriented-php/.

DoubleDee

Thanks for the comments but that doesn't answer my original post...

Debbie

DoubleDee

I am trying to learn how to work entirely with objects using OOP.

My goal was (and still is) to learn how to take a User's Comments and put them immediately into an object.

(This would be a good first step. And once the User's comments are in an object, then I can start passing it around to other objects.)

Would someone please help me to get my code working?

Sincerely,

Debbie

NogDog

DoubleDee;10967891 wrote:
Thanks for the comments but that doesn't answer my original post...
Debbie

Well, I was trying, at least with regard to this part:

DoubleDee;10967847 wrote:
...I am trying to learn object-oriented programming along with learning more about PHP....I have a decent programming background but have never really understood OOP, and it is hard to go from "Hello World" examples in a book to building a real website using OOP.
...

To really use OOP the "right" way, you need to understand the rationale behind it, which is what I was trying to push you toward. Simply learning the syntax for defining a class, instantiating it, and accessing its members won't do much to teach you about OOP.

Right now the only object you have is in the file you call with your form, with a couple typos which I fixed here, plus added the use of print_r() to help see what is in the array you are inspecting at the end:

class CommentsForm
{
   protected $inputsArray;
   function __construct($inputs)
   {
      $this->inputsArray = $inputs; // changed $inputsArray to $inputs

   }
   public function getInputs()
   {
      return $this->inputsArray;
   }
}

$objCommentsForm = new CommentsForm($_POST);
// added back-slash in string literal and used print_r():
echo "\$objCommentsForm->getInputs() " . print_r($objCommentsForm->getInputs() , 1);

As to what you want to do/know next, I don't really know as I don't know what your goal/expectations are (other than the general PHP-OOP info I referenced in the prior reply). Right now all the class does it wrap up $_POST in a class, which doesn't really gain you anything right now -- but might if/when you add other methods to it to manipulate and/or validate that data, and so forth.

DoubleDee

NogDog;10967894 wrote:
Well, I was trying, at least with regard to this part:

To really use OOP the "right" way, you need to understand the rationale behind it, which is what I was trying to push you toward. Simply learning the syntax for defining a class, instantiating it, and accessing its members won't do much to teach you about OOP.

And I appreciate that, but I was getting tired of reading books that don't relate to the real world. (I'll be 65 before I build anything at that rate?!) :eek:

Right now the only object you have is in the file you call with your form, with a couple typos which I fixed here, plus added the use of print_r() to help see what is in the array you are inspecting at the end:
class CommentsForm
{
   protected $inputsArray;
   function __construct($inputs)
   {
      $this->inputsArray = $inputs; // changed $inputsArray to $inputs

   }
   public function getInputs()
   {
      return $this->inputsArray;
   }
}

$objCommentsForm = new CommentsForm($_POST);
// added back-slash in string literal and used print_r():
echo "\$objCommentsForm->getInputs() " . print_r($objCommentsForm->getInputs() , 1);

Thanks for catching the type-o.

Why didn't my original echo statement work?

As to what you want to do/know next, I don't really know as I don't know what your goal/expectations are (other than the general PHP-OOP info I referenced in the prior reply). Right now all the class does it wrap up $_POST in a class, which doesn't really gain you anything right now -- but might if/when you add other methods to it to manipulate and/or validate that data, and so forth.

Well, that was the direction I was thinking of heading in.

I figured if I could learn how to take data from an HTML form and put it into an object, then I would have something to play with. For example, I could pass that object into a Validation Class or an Email Class or maybe a Database Class or whatever, right?

When you do proper OOP, aren't you supposed to do everything INSIDE of objects and BY PASSING OBJECTS?? (As opposed to working on naked data like the $_POST array or by passing naked data between objects??)

I am open to suggestions and coaching.

I just figured working with the $_POST array itself and passing arguments between web pages and functions was about an UN-OOP as you can get...) :queasy:

Sincerely,

Debbie

NogDog

DoubleDee;10967895 wrote:
And I appreciate that, but I was getting tired of reading books that don't relate to the real world. (I'll be 65 before I build anything at that rate?!) :eek:

My experience -- and that of many from what I've seen -- is that learning OOP often begins rather confusingly and maybe frustratingly, and then you have a few "eureka" moments where it starts to come into focus and make sense, and then you come to really appreciate it and like it. My moment came while reading Matt Zandstra's PHP 5 Objects, Patterns, and Practice, but that was on top of other reading of articles and blogs, so no guarantee it would be your personal "sliver bullet".

Why didn't my original echo statement work?

It would work, but it would only say something like "array()", not telling you what is inside of it.

I figured if I could learn how to take data from an HTML form and put it into an object, then I would have something to play with. For example, I could pass that object into a Validation Class or an Email Class or maybe a Database Class or whatever, right?

When you do proper OOP, aren't you supposed to do everything INSIDE of objects and BY PASSING OBJECTS?? (As opposed to working on naked data like the $_POST array or by passing naked data between objects??)

I am open to suggestions and coaching.

I just figured working with the $_POST array itself and passing arguments between web pages and functions was about an UN-OOP as you can get...) :queasy:

Depending on your point of view, a strength or weakness of PHP is that it is not an OOP-only language, so you can mix procedural code and OOP code (and spaghetti code) as desired to suit your skill, style, and functional requirements. In fact, you will always need at least a few lines of non-OOP code, if for nothing other than to launch your main object that would drive everything else.

Doing something like what you have started is probably a good idea, in that it is something you can re-use in multiple applications. Of course, a year from now, whatever you come up with now you'll probably think is junk and completely rewrite it anyway. 😉 The main thing I think that OOP requires from you perhaps more than less structured techniques is more forethought about your high-level and then mid-level design. Then you start getting into object-oriented analysis/design (OOAD), which can ultimately be more important than your coding syntax knowledge/skills.

Well, that's enough typing for tonight. Good luck!

DoubleDee

NogDog;10967896 wrote:
My experience -- and that of many from what I've seen -- is that learning OOP often begins rather confusingly and maybe frustratingly, and then you have a few "eureka" moments where it starts to come into focus and make sense, and then you come to really appreciate it and like it. My moment came while reading Matt Zandstra's PHP 5 Objects, Patterns, and Practice, but that was on top of other reading of articles and blogs, so no guarantee it would be your personal "sliver bullet".

I've heard that is a good book.

It would work, but it would only say something like "array()", not telling you what is inside of it.

Actually it threw an error.

Doing something like what you have started is probably a good idea, in that it is something you can re-use in multiple applications. Of course, a year from now, whatever you come up with now you'll probably think is junk and completely rewrite it anyway. 😉 The main thing I think that OOP requires from you perhaps more than less structured techniques is more forethought about your high-level and then mid-level design. Then you start getting into object-oriented analysis/design (OOAD), which can ultimately be more important than your coding syntax knowledge/skills.

Well, that's enough typing for tonight. Good luck!

Thanks for the code corrections, and feel free to keep helping me out!

It would be nice if I could actually start building a real life application.

I would like to build a website where people can register and log in and post comments and so on, sorta like PHP Builder.

I have lots of ideas, but I also need lots of help doing even the simplest things like this thread. :o

Hope to speak again...

Debbie

NogDog

Well, if I were going to build such a sight, I'd probably do something like PHPBuilder does: use a 3rd-party software package (vBulletin in this case, and there are dozens of open-source PHP-based forum packages out there). 🙂

DoubleDee

NogDog;10967898 wrote:
Well, if I were going to build such a sight, I'd probably do something like PHPBuilder does: use a 3rd-party software package (vBulletin in this case, and there are dozens of open-source PHP-based forum packages out there). 🙂

Um, I'm here to learn PHP and OO programming, not how to buy and install software... 😉

DoubleDee

So, NogDog (or anyone else), some more questions for you...

Thanks to your help, my code works, but I'm not sure it does what I want yet.

So, now I have a class that should be able to process any form that is submitted to it by placing the form inputs into an array.

But is there any easy way to get the field names and field values out easily and into individual variables?

Let's say my array has:

name => Debbie
date => 11/10/2010
comments => I need help with OOP!

How can I automate things so that I can create the following variables in my class:

name
date
comments

and then assign the values:

Debbie
11/10/2010
I need help with OOP!

If I could figure that out, then I should be able to use this class on any form and have an easy way to out the object's array's contents, right?

I could have a Comments Form with 3 fields or an Address Form with 12 fields or a Log-In Form with 2 fields and there would be an easy way to work with the form's input values.

Suggestions welcome...

Debbie

NogDog

You may want to use a "magic" get() method (note that is a double underscore).

/**
 * Getter for $data array
 * @return string
 * @param string $var Array key
 */
public function __get($var)
{
   return (isset($this->inputsArray[$var]) ? $this->inputsArray[$var] : null;
}

Then you can access each array element as if it were a separate object variable:

$formData = new CommentsForm($_POST);
var_dump($formData->name); // look at the value from $_POST['name']

DoubleDee

Does that sound like a good strategy?

I figure it is a way to start using objects first thing and it makes my class reusable, right?

Debbie

NogDog

DoubleDee;10967993 wrote:
Does that sound like a good strategy?

I figure it is a way to start using objects first thing and it makes my class reusable, right?

Debbie

It'll be more reusable if you give it a more generic name. 🙂

Possibly a more OOP approach would be to have each form field be an object, and then you would have a form object which would be a collection of those form objects. That way you could have different classes for different types of form elements, each extending a parent, generic or abstract FormField class.

DoubleDee

NogDog;10967996 wrote:
It'll be more reusable if you give it a more generic name. 🙂

A wise guy, I see!!! :p

(I was just makin' sure you were payin' attention!!)

Possibly a more OOP approach would be to have each form field be an object, and then you would have a form object which would be a collection of those form objects. That way you could have different classes for different types of form elements, each extending a parent, generic or abstract FormField class.

Sounds like an interesting approach.

So, are you gonna play hard to get and help me figure that out, or do I have to play "hard to get"?! :evilgrin:

Before moving on to that, so what exactly would be the big benefit in splitting things out like that? I didn't quite get the "value added benefit" from what you were saying...

Debbie

DoubleDee

NogDog,

I'm not really sure how to create what you suggested, but here is my best guess...

abstract class FormField{
	protected $name;
	protected $type;
	protected $value;
}

class TextFormField{
	function set($formName, $formValue){
		$this->name = $formName;
		$this->type = 'text';
		$this->value = $formValue;
	}

function get(){
	return $this->value;		
}
}

// and so on...

Debbie

NogDog

OK, I'm not saying this is the way to do it, or even how I'd do it, but I think it's a halfway decent illustration of what I was thinking:

<?php

/**
 * One form field (element)
 */
abstract class FormField
{
   protected $name;
   protected $value;
   public function __construct($name)
   {
      // cannot have spaces in name
      if(preg_match('/\s/', $name)) {
         throw new Exception("Invalid name '$name'");
      }
      $this->name = $name;
   }
   /**
    * Make the setter abstract so that child decides about any validation
    */
   abstract public function set($value);
   /**
    * Getter
    */
   public function __get($var)
   {
      if(isset($this->$var)) {
         return $this->$var;
      }
      throw new Exception("Invalid varname '$var'");
   }
}

/**
 * A Text type of form field
 */
class TextFormField extends FormField
{
   /**
    * Strip out newlines/nulls from text fields:
    */
   public function set($value)
   {
      $value = preg_replace('/[\r\n\x00]+/', ' ', trim($value));
      if(get_magic_quotes_gpc()) {
         $value = stripslashes($value);
      }
      $this->value = $value;
   }
}

/**
 * This will be an aggregation of FormField objects
 */
class Form
{
   private $fields = array();
   private $name;
   public function __construct($name)
   {
      $this->name = $name;
   }
   /**
    * We can use type-hinting with the top-level abstract class's name
    */
   public function addField(FormField $field)
   {
      $this->fields[] = $field;
      return $field; // so user can reference directly if they want
   }
   public function getFields()
   {
      return $this->fields;
   }
}

// Let's try it out:
try {
   $form = new Form('test');
   $field1 = $form->addField(new TextFormField('field_1'));
   $field1->set("this is a test");
   $field2 = $form->addField(new TextFormField('field_2'));
   $field2->set("This is only a test.");
   echo "<pre>".print_r($form,1)."</pre>";
}
catch(Exception $e) {
   echo "<pre>".(string)$e."</pre>";
}

And it outputs:

Form Object
(
    [fields:private] => Array
        (
            [0] => TextFormField Object
                (
                    [name:protected] => field_1
                    [value:protected] => this is a test
                )

        [1] => TextFormField Object
            (
                [name:protected] => field_2
                [value:protected] => This is only a test.
            )

    )

[name:private] => test
)

Next step might be to add methods for things like outputting [X]HTML for each type of form element (implying another abstract method in the FormField class, your validation methods, and so on.

DoubleDee

Thanks for the response NogDog, but, wow, I'm a bit overwhelmed by your code...

Care to help me figure things out?

Debbie

NogDog

Probably the key thing to grasp there is how TextFormField class is a "child" of the abstract class FormField. FormField defines data and methods that are expected to be common to all form fields, including an abstract method named "set()". An abstract method doesn't do anything itself (in fact, it's not allowed to), but any non-abstract class that extends that class must define that method. The rationale here is that each different type of form field might have different types of values it will allow (e.g., a textarea can have newlines, a text input cannot), so each will have different types of filtering to perform on those values. (I'm not sure I'd really do this, but it was the first thing I thought of for an example.) So, when we define TextFormField and have it extend the FormField class, TextFormField inherits everything from FormField that is not private (i.e. public and protected variables and methods). All it does in this case is the minimum it has to do, which is define the inherited abstract set() method.

The Form class is then set up to be a collection (or "aggregation" in OOP speak) of FormFields, so its $fields array will be an array of FormField objects. Any child object is considered to be both its specific class plus its parent class, so TextFormField can be considered to be both a TextFormField object and the more general FormField object. This is why the Form::addField() method can use "FormField" for the type-hinting, yet still accept a TextFormField object without failing.