OOP Please set me straight.

[fjm]

Hello everyone.

I have a project that I am going to be working on and I have created a html helper class. That class looks pretty good if I do say so myself. :)

I think I am missing out on the big picture of OOP though. The way in which I am using this helper class is in my index file like so:

[PHP]
$html->TROpen();
$html->TDOpen();
echo " ";
$html->TDClose();
$html->TDOpen();
$html->Input('submit','submit','Save Data');
$html->TDClose();
$html->TRClose();[/PHP]
This of course will build two td cells with a submit button. What I am seeing that does not look right is that this resembles more procedural programming than OOP. After I have repeated this sequence of, for example, 10 td cells, I am thinking that there has to be a better way to do this.

It seems to me that maybe I should be extending the helper class to a different class where I build the different boxes I need then call those boxes in my index file. Am I correct on this?

I feel like I am almost there guys in my quest for understanding how to implement OOP. :)

Thank you for any input!

Frank

[fjm]

Now I am wondering if it would be easier and or better to just forgo the helper class and code straight html into a forms or template class instead.

I just want to have a solid html foundation before I start this venture. I am open to any suggestions.

Thanks,

Frank

[coolsti]

Go with the OOP route. When you have more of a feel for OOP you can do this very elegantly. I did.

I have made three classes: a table class, a row class and a cell class.

The table class contains an array of row objects. It also contains a function to add a row, and to add whatever extra formats I wish to print out in my TABLE tag.

The row class contains an array of cell objects. It also contains a function to add a cell, and to add whatever extra formats I wish to print out in my TR tag.

The cell class contains the cell content. It also contains a way to add whatever extra formats I wish to print out in my TD tag.

Now here is what is nice about the OOP implementation: A cell object can contain another table object as its content.

The table class contains a "print" function to print the table and its contents out to the user. The table's print function will print out the TABLE tag and whatever formats, and then go through its array of row objects and call the print function of each row. The table's print function will then close the /TABLE tag.

The row's print function will print out the TR tag and whatever formats, and then go through its array of cell objects and call the print function of each cell. The row's print function will then close the /TR tag.

The cell's print function will print out the TD tag and whatever formats, and then will check if its "content" contains a print method. If so, then the content is another table. In this case, this table's print function is called, and here we see that we print out embedded tables recursively. If not, then the content is just text and is printed out. Finally, the print function will close the /TD tag.

The bad thing about my technique is memory: The entire page content is first built up in memory, in the various table, row and cell objects, and then printed to the user at once (but it is always possible to print out parts of a page at a time).

The good thing is that using the table, row and cell class functions, it is very easy to build up and reformulate a page layout, and I never ever make any mistakes with matching the opening and closing html tags for the TABLE, TR or TD, because these are handled automatically by the classes and their print functions ;)

So go OOP. It will pay in the long run.

[pbmods]

Heya, Frank.

If you want to model a table, model it as something that makes more sense to PHP, such as a two-dimensional array.

E.g.,

$table =
  new HTML_Table
  (
    array
    (
        array( ' ', HTML_Input::buildHTML('submit', 'submit', 'Save Data') )
    )
  );
 
echo $table->renderHTML();
 

HTML_Table::renderHTML() would then build the table, and you'd end up with something like this:

<table>
  <tr>
    <td>&nbsp;</td>
    <td><input type="submit" name="submit" value="Save Data" /></td>
  </tr>
</table>
 

[fjm]

Hey Coolsti,

Thanks for sharing and the lengthy explanation. I always enjoy another view point. :)

Since I have more procedural experience than OOP, it would seem "natural" to want to lean more that way, however, these past few months, I have been doing more and more OO programming. I like the way it looks and ultimately works and especially love the reusability factor!!

I am plagued with the question "Am I taking this OO too far. I love your idea of the helper classes and a while back had the exact same idea where I would use a class to build cells into an array but thought that it was overkill. My personality is such that I would prefer to take things all the way out to the extreme but then I get bogged down with the tiny details and loose focus of the big picture.

I guess what I am looking for here is a balance. A healthy balance at that. Something inside is telling me to include() the header and footer and build the body using OOP. Actually, the header will also be in a class because of the need to dynamically change the meta tags, javascript, etc. I would just include() the footer.

What I have come to realize this past 10 minutes is this.. What is the difference of writing:

<tr>
 <td colspan="2" bla="bla">blabla</td>
</tr>
 

Or writing:
[PHP] $html->TROpen();
$html->TDOpen();
echo "My cell data goes here";
$html->TDClose();
$html->TDOpen();
$html->Input('text','','','','','40','40');
$html->TDClose();
$html->TRClose();[/PHP]
I must be missing something because to me, I see that it is exactly the same. What is the advantage to using OOP in the way that I have it over coding straight markup?

[fjm]

Hey PBMods,

You have to be one of the very best php programmers I have seen because you (Atli included) are one of the only people that can throw a snippet at me that makes me say "waaa??" I am always left scratching my head. :)

Ok, I gotta ask... and I'm sure I should know this, but, what is the "::" operator in your code? What do we call that?

I think I see what your code snippet does and it is WAY cool if I am reading it correctly. Ultimately, it builds the exact same thing (as you also provided in your example) that I have made.

So wadacall what I posted? Is it like procedural with OO tendencies?

As I posted above, What I want to accomplish is to strike a balance here on this project. I am after code reusability and ease. One thing about this project is that it has the potential to scale. When I was not using OOP my programs started to bloat and they were a real mess. Thankfully, OOP has taken a lot of that away.

I am always after honing my OO skills and sometimes loose sight of the project at hand because my mind doesn't stop thinking about how I could always make the code more automated.

[coolsti]

Some years back I was relatively new to PHP, but not to OOP, although I am an engineer and not educated as a software developer. When I started to code an application in PHP I was not using the OOP technique, but hand coding all the table, tr and td tags.

This was fine for setting up a page or two. But as soon as I started to want to add to my pages, and modify their format (my application is table based, rather than CSS based for design) I realized what a difficulty it was to do this kind of editing with so many html tags mixed in with php scripts. I was constantly getting lost in which start tag belonged to which end tag, and was constantly missing tags here and there.

I then spent some time to build my classes, and bingo, my development efficiency increased as dramatically as the speed of a mysql query when adding a badly needed table index! It was worth the effort to make the classes!

I believe that you can indeed take the OOP thing too far. Try to look at the code of something like oscommerce :), it is quite difficult to understand. But I have by and by added more OOP to help me build my pages. For my application, I found the common things that appear on all pages, and then placed them in classes. I have a class that actually formats and prints my entire page, making the html header section, adding the body section and then a footer section. I use various functions to allow me to adjust the page to how it must look for the requested page (e.g. what buttons should appear in a banner) and the content itself is just fed in as table objects from my table class. By placing all the commonality into a class, I can now build up a new page very quickly.

I have gone even further where I make my pages look like tabulated views, giving the impression that the user is opening a new tab by clicking on a button that looks like a tab. The OOP thing here is that I use a class to handle the look and functionality of the tabs on a page. And the primary code that is called when someone clicks on a tab is exactly the same, but each tab handles a different item in my application, and I put all the "specific" functionality for each item in a class for that item. I use an "item factory" at the start of the script to create an instance of the correct item for that page request. Why this helps me is again due to the commonality in my application: Now when I need to add a new tab view or add a new tab to an existing page (for a new item I need to handle) the coding is very rapid! Any one of my existing item classes serves as a template for the new item, I just need to empty out all the functions and write what is needed for the new item!

So OOP can indeed help ;)

By the way, to answer your question, there isn't much difference between the two ways that you show in your reply to my reply. Calling a class function named close() just to print out the closing TR or TD tag doesn't give you much benefit over just echo'ing out the closing tag directly. Much better, and the reason why I wrote my table classes in the first place, is to allow the classes to do a lot of the menial work for me. Here is what my code might look like:

$table1 = new mytable("border:0");
$table1->addCell("first cell in first row");
$table1->addCell("second cell in first row");
$table1->newRow();  // adds a new row object to this table
$table1->addCell("only cell in second row","colspan:2");
 
$table2 = new mytable("border:0");
$table2->addCell("first cell in second table");
$table2->newRow();
$table2->addCell($table1);
$table2->newRow();
$table2->addCell("last row in table 2");
 
$table2->myprint();
 

Here you see I never myself print a table, tr or td tag. Nor do I ever try to close one of these tags. The print function (which I call myprint) of my table, row and cell classes does all this for me. Also note that I do not add a cell to a table row by invoking a row class object function directly. My table class takes care of this for me, letting me code the format of the page more easilly.

[fjm]

Coolsti,

Thanks again for the help and also for the code sample. Sometimes the sameple makes all the difference.

Let me ask you a question. I see your myTable and am wondering if you have started your <tr> in that method because I don't see anything in your call that would indicate otherwise. Am I correct?

Your right. I do not see a need to echo a closing <tr> or any closing tag for that matter. What I have had a hard time understanding is if lets say, I wanted to have 2 or 3 or 6 or whatever quantity of <td> tags. The only way I can see to do that would be to build them in an array and then return them. Am I correct on this?

Also, in your code sample, I don't see an allowance for colspan or other html attributes. What do you do if you need to use colspan, rowspan, etc? I'm thinking that you probably have that programmed in your method but have omitted it and added the comment instead. Am I correct?

Thanks Coolsti!

Frank

[coolsti]

Maybe this will clarify it for you somewhat. I show below only the print function for all three of my classes. I have removed some things in order to make this easier to understand. I have removed extra stuff that allows, for example, the addition of things before or after the table tag.

The print function of the table class:

 
    function myprint()
    {
        echo <table " . $this->format . ">";
        foreach ($this->rows as $row)
        {
            $row->myprint();
        }
        echo "</table>";
    }
 

The print function of the row class:

 
    function myprint()
    {
        echo <tr $str1 $this->rowformat > ";
        foreach ($this->cells as $cell)
        {
            $cell->myprint();
        }
        echo "</tr >";
    }
 

The print function of the cell class:

 
    function myprint()
    {
        echo "<TD . $this->format . ">";
        if (method_exists($this->cell,"myprint"))
        {
            $this->cell->myprint();
        }
        else
        {
            echo "$this->cell";
        }
        echo "</TD>";
    }
 

Note where the actual printing (that is, echo'ing) of the HTML tags TABLE, TD and TR occur. The cell myprint function wraps the TD start and end tag around the cell content. The row myprint function wraps the TR start and end tags around the row content. But here, the row content is the row object's array of cell objects, so the row print function is just calling the cell print function for each cell object in its array. The table myprint function wraps the TABLE start and end tags around the table content, which here is an array of row objects.

Note that the cell myprint function checks to see if what it is holding as content is simply a string, or is another object with its own myprint function. If the latter is true, it must be holding another table, and so the content's myprint function is called, which then allows for printing out recursively the table structure of an entire page. Because of the placement where the HTML start and stop tags are printed, the syntactically correct tag formatting is maintained for me automatically!

I believe what I am doing above is known in design patterns as the container pattern. Each table contains rows which contain cells, but a cell can then contain a table which in turn contains its rows and its cells, etc. etc.

[Markus]

CodeIgniter (<3) has a nice Table Class. You could gander at the source for it; see how they do it.

[coolsti]

Yes, this sounds like a much more polished table class than the one I whipped up for my own use. Would be very educational to look at some of their code if it is open to you. I must do that myself sometime :)

[Atli]

Hi.

If I were to design a system like this, I would have it work somewhat like this:

$table = new Table();
 
$row = new Row();
 
$col1 = new Column("Text in column 1");
$col2 = new Column("Text in column 2");
 
$row->AddColumn($col1);
$row->AddColumn($col2);
 
$table->AddRow($row);
 
$table->Print();
 

Looks similar to how you would construct a table using DOM in JavaScript.

But, as has been suggested, this is no less work than simply echoing the HTML as text. More even.

So I've never used anything like this in practice. I tend to use some sort of a template system, like Smarty. That also makes it easier to manage different styles, if you need such a feature.

[fjm]

Thanks everyone for the suggestions and samples. I have to agree with Atli, I think that there may not be any real advantages in writing a html class over coding straight html.

I remember when I was programming procedurally, I would copy and paste hundreds of times, the same exact code. I do not want to do that anymore.

Maybe my efforts would be better spent writing a class where common blocks of html can later be called to build the page OR would it be more correct to build an entire page as a method with the processing it requires and just call that method. The pitfall to this that I see is that I am only using that page once so I don't see the benefit from using it as a method.

Maybe I am wrong here, but what I *think* should be happening is that in my index file, I should be using only calls to build the page. Right? Instead of a whole lot of processing. The processing should be handled within its method.

[fjm]

CodeIgniter (<3) has a nice Table Class. You could gander at the source for it; see how they do it.

Wow. I never saw that before but it looks almost identical to the methods I have coded.

[pbmods]

So I've never used anything like this in practice. I tend to use some sort of a template system, like Smarty. That also makes it easier to manage different styles, if you need such a feature.

Amen.

It's a good exercise in OOP, but any kind of HTML modeler has very limited application in a practical setting because:

• it is practically impossible to handle one-offs and exceptions.
• it enmeshes your business and display logic, which makes it tricky if you need to make a change to only one or the other.
• it ends up involving way more code and processing than if you'd just stuck with static HTML and a couple of PHP echo statements.

I guess that last one's not totally fair; procedural code is always faster than object-oriented. But OOP is more modular, scalable and maintainable.

By the way, the "::" operator (affectionately known as "nekudotayim paamayim") is the static operator. It is used to execute static methods and access static properties of a class (these are methods and properties that are "owned" by the class itself rather than a specific instance of the class).