PHP - OOP or don't bother?

[Mikalee]

Hey people,

I'm a developer (mostly with ASP/.NET) with little php experience (mostly installing/maintaining open source software). I'm planning to create a new PHP application and was wondering if I should take the OOP route or not. I'm comfortable with OOP and understand the advantages, but this application is not too big (about 5 forms and maybe 5-8 dynamic pages) and I need to create this application quickly.

So, given the limited knowledge you now have of me and the application, would you

a) Build it with procedural PHP code (inline design, etc)
b) Build it with OOP php code (separate UI/Business logic)
or c) Use some sort of existing php framework to develop it (e.g. cakePHP or such).

Thanks in advance.

[Vin DSL]

I'd steal someone else's "open source software", rearrange it to suit myself, and call it my own!

That's what all us PHP developers do!

It's a PHP thing, I guess...

[jason]

I tend toward OOP, but it can be overkill if the project is vey small. My "framework" of choice is PEAR (http://pear.php.net). PEAR is really just a collection of classes, not a rapid application development environment like Cake, but I find it gives me a lot of flexibility without too much unnecessary overhead.

--Jason

[mattsiegman]

It depends on what you're doing. I've never used OOP in PHP unless it has been forced on me. If it's just a simple site, it may be easiest to just go procedural with it, and write a common include file for your common functionality

[Mikalee]

Thanks for the completely different responses!

I'm thinking my best option for this particular app would be to write OOP code (as I haven't seen anything similar to what I want in open source, vin). It is a relatively simple app, but there's a very good chance that I'll need to continue to extend it's functionalities.

But, it being my first php app from scratch, I'm not sure what the best way to go about it would be. I'm sure I can read tutorials and write all the entity objects myself, but I'm not sure what the best (or just reasonable) way of integrating those objects in the app is. I.e. say I create classes to represent employees, orders and products (not my app, just an example), what's best practice to use these classes and create the UI. Should a templating system be used (I've read a lot of negative views on them here)?

Or maybe I should look further into PEAR as it will probably help with some of the tasks (DB abstraction, and others probably - does it help with templating?).

I realize I'm asking questions that are very dependent on me and the specifics of the app, but I'm just hoping for some general guidelines & pointers.

Thanks again.

[the_ancient]

Thanks for the completely different responses!

That is the best part of PHP, you do what you want

Freedom!

I'm thinking my best option for this particular app would be to write OOP code (as I haven't seen anything similar to what I want in open source, vin). It is a relatively simple app, but there's a very good chance that I'll need to continue to extend it's functionalities.

Wise choice IMO

But, it being my first php app from scratch, I'm not sure what the best way to go about it would be. I'm sure I can read tutorials and write all the entity objects myself, but I'm not sure what the best (or just reasonable) way of integrating those objects in the app is. I.e. say I create classes to represent employees, orders and products (not my app, just an example), what's best practice to use these classes and create the UI. Should a templating system be used (I've read a lot of negative views on them here)?

PHP itself is a "templating system" after all that is how it started. The Major Template System out there like Smarty, Basically Repeat standard Functionality

So Instead of

<? echo $content; ?>

you would have

{content}

then then 5 lines of code telling smarty what {content} is.

Waste of resources IMO

Or maybe I should look further into PEAR as it will probably help with some of the tasks (DB abstraction, and others probably - does it help with templating?).

There are template classes in Pear, just about everything you need is in PEAR

I realize I'm asking questions that are very dependent on me and the specifics of the app, but I'm just hoping for some general guidelines & pointers.

Thanks again.

Keep Asking.

[jason]

OK...completely different answer number 2:

I tend to use templating to separate my "business logic" from my display. To do that I tend to use Smarty. Of course, if you are worried about the added resource use of Smarty, you can still separate the two using native PHP:

File: bizlogic.php

<?php
    //do all of your processing here, place any important values in variables
?>

File: output.php

<?php
    //include bizlogic.php, it will automatically do the processing
    require('bizlogic.php');

    //now all of the variables you defined in bizlogic.php are available
?>
<html>
  <head>
    <title><?php echo($page_title); ?></title>
  </head>
...

As for PEAR, some of the packages you might want to check out:
MDB2 - database abstraction (this is the latest and greatest of several abstraction packages available)
HTML_QuickForm - helps you create forms; handles validation and error messages, default values, etc. automatically; will save you LOTS of time if you have even semi-complex forms
Structures_DataGrid - can be tricky to get working right, but automates the process of making tabular representations of database records with paging and sortable columns
HTML_Table - the parent of DataGrid, a more basic way to make data tables that's much easier than trying to write out the table HTML linearly.

If you have a more advanced app and you don't mind adding a bit more overhead you might also check:
DB_DataObject - creates class deifinitions for each of the tables in your database, allowing you to interact with the data without having to wite SQL queries
DB_DataObject_FormBuilder - automatically creates QuickForm forms from DataObject table definitions; great for rapid prototyping

There are also four or five template classes in PEAR, but I have very little experience with them.

If you go the OO route in PHP I highly encourage you to use PHP 5. The object support is much more mature than it was in PHP 4. There are some compatibility issues between 4 and 5 that have stunted acceptance of PHP 5, but since you are starting anew definitely go with PHP 5 from the start.

The fun thing about PHP is that it is so broad and so flexible that everyone has their own way of working and their own theory of what are best practices. So getting multiple completely different answers to your questions is par for the course. My best advice is to experiment and see what works for you and then run with whatever you think works best. No matter what you do you'll find one person who says you do it completely wrong for every person that supports you.

You know the saying--never talk politics, religion, or PHP.

Good luck.

--Jason

[Mikalee]

That's great...exactly the kind of advice I was hoping for!

So, here's what I'm thinking so far:

1) create custom classes to represent each object (e.g. emplyee, product, order) named something like employee.class.php

2) create business logic pages for each page on the site. e.g. employees.php which would use the employee.class.php to add/edit/update employee information, store it in local variables and pass them to...

3) create output pages as needed. I guess it would make sense to create a main template file (template.php) which would have place holders for the different kinds of information it expects. But it might be easier just to create a template folder for each 'view' or site page - what would you guys do?

Finally, it does seem like the PEAR classes could definitely make things easier (any reason not to use PEAR)? I think all the ones you (Jason) mentioned would be very useful. Though I'm not entirely sure how some of them would interact with my custom objects (i.e. how the HTML_Quickform object interact with my employees object)...does anyone know of any sample code I could look at to get a better idea?


Thanks again, this has been great.

[jason]

HTML_QuickForm takes an array of default values, so your objects could implement a toArray() method that sets up that array. The array should be an associative array in with keys set to the form field names and values set to the current values.

Once the form is submitted there are several ways to process the submitted data, where you could place the info back into the object.

First, setting up your form:

$obj = new MyObject();
$obj->loadData('whatever');

$form = new HTML_QuickForm('myForm');
//add your form fields, filters, and validation rules here
$form->setDefaults($obj->toArray());

//Upon successful submission $form->validate() will return true
if($form->validate()) {
    //if the form passes validation this code will run

    //insert scenario of choice from below

    //we're done echo your message and stop script execution
    exit(0);
}

//display the form
$form->display(); 

QuickForm offers two methods to get final values out: exportValue() and exportValues(). exportValue() takes a field name as an argument and returns the value of that field as a string. exportValues() take no arguments and returns all of the values in an associative array in the same form as the array accepted by setDefaults().

Scenario 1:

if($form->validate()) {
    $obj->setName($form->exportValue('name'));
    $obj->setFavoriteColor($form->exportValue('favoriteColor'));
    ...
} 

Scenario 2:

if($form->validate()) {
    //pass all form data to a method of the object
    $obj->updateData($form->exportValues());
} 

Scenario 3:
QuickForm also has a process() method that accepts a callback. This example will achieve the same result as Scenario 2.

if($form->validate()) {
    $form->process(array($obj, 'updateData'));
} 

Hope this helps.

--Jason

[Mikalee]

Thanks Jason.

Do you normally 'install' your own PEAR lib for each site you create or do you used the one provided by Jag? If the latter...are the packages you mentioned included?

Also, is there anything more to installing PEAR than just copying the classes in a local folder? Are there configuration changes the install script makes behind the scenes?

And, last but not least, do you use an IDE for php programming or just a text editor?

Thanks!

[jason]

I've installed my own PEAR repository, although you can ask support to install packages into the main repository for you if you prefer. Personally, I'd prefer to have everything under my own control. Although you can download packages from the web and unzip them into your site, it is much easier to use the PEAR Package Manager to do your installs.

Since JPC already has the package manager installed you can try following these directions to create a local repository in your account. When I first set up my repository however, JPC was running an old version of the package manager and I had trouble with it, so I did a full install of the then-latest version in my account. It is pretty easy to do.

If you have SSH access, I would recommend doing the following:
*Download and run the go-pear.org script. You can do this with a single command:

lynx -source http://go-pear.org/ | php

This command downloads the page and dumps the source to STDOUT, which get diverted to the PHP interpreter and executed.

*As the script runs you will be asked several questions, most of which you can answer by pressing <Enter>. When you get to the menu with the "suggested file layout" choose option 1 (Installation prefix) and change the value to something like "/home/USERNAME/pear." I'd also change the PHP code directory to something like "$prefix/php." If you don't you'll end up with your PHP directory in /home/USERNAME/pear/lib/php (with nothing but the php directory in lib). If you don't change it the world won't come to an end, but I just prefer a shorter path.

* When you are done making changes, press <Enter> and, if all goes well, the repository will be created. You will then have a local copy of the package manager at /home/USERNAME/pear/bin/pear. I've created a "shortcut" by creating an alias in /home/USERNAME/.profile as follows:

alias mypear="/home/USERNAME/pear/bin/pear"

Once you do this, type "source .profile" on the command line to reload the .profile and make the alias active. The you can type "mypear" anywhere in your account to access your local copy of the package manager.

The package manager is pretty easy to use. To install a package just type:

(my)pear install package_name

In the package manager context package names are not case sensitive. If a package has required dependencies you can use the -o flag after install to automatically install the dependent packages as well:

(my)pear install - o HTML_QuickForm

You can get a full list of all of the PEAR package manager commands by typing

(my)pear help

To get help on a specific commanf use

(my)pear help command_name

If you are installing PEAR on a server where you don't have shell access, open http://go-pear.org in a local browser, save the code as go-pear.php, and upload it to a directory in your web space that can be written to by PHP (on most non-JPC installs this means chmod 777). The go to http://yoursite.com/YOURDIR/go-pear.php and a web installer will load. Fill out the form and click go and a web-based package manager will be installed which can be accessed at http://yoursite.com/YOURDIR. I don't recommend this unless you have no other options, however: your repository is in public viewable web space (although you can password protect it) and your package files will generally be owned by "nobody."

Finally, before you can use your local scripts in your site you need to include your path to PEAR in your php.ini. What I do is open a phpinfo() script in the browser and find the include_path setting, then I insert my local pear path (/home/USERNAME/pear/php, /home/USERNAME/pear/lib/php, /home/USERNAME/public_html/pear, or whatever). I generally do this before the server-wide pear path (generally /usr/share/pear or /usr/lib/php) so that my copies of packages will be used over the server-wide versions if both exist. It is important to do this (rather than using absolute paths in your include()/require() command) because many packages load other packages with relative paths and this will fail if the pear directory is not in the include_path.

Finally, for many years I coded all of my PHP using a text editor. I've mainly used Editeur and Crimson Editor. Recently however I began playing with an Eclipse setup that includes PDT (PHP Development Tools), Aptana (a "Web 2.0" editor [JavaScript, HTML, etc.]), and Subclipse (a subversion repository client for version control) and I have since started using that as my IDE for most of my work. Note that Eclipse is running in Java so it can be quite slow. On my older computers it can take several minutes to start up (on my new Core 2 Duo laptop it takes about 30 seconds! Woot!).

I hope this makes sense and answers your questions. Let me know if you have any more questions.

--Jason

[Gwaihir]

Yet another completely different response..

I've you're going to use PHP5, I'd suggest you check out the Zend Framework, which has recently gone 1.0. PEAR is a collection of packages of very varying quality, completeness and ability to work well with other packages. The Zend Framework is IMHO far more accessible, as it is an extensive well thought out whole, yet still very open. I.e. you can easily use just those parts of it you like. It also has a lot of momentum these days, which means nice tutorials and such are relatively easy to come by.

2) create business logic pages for each page on the site. e.g. employees.php which would use the employee.class.php to add/edit/update employee information, store it in local variables and pass them to...

Well, more or less. You'll find they have a LOT in common, each setting up practically the same set of includes, etc. Therefore I wouldn't make those actual pages directly accessed by the browser, but controllers. You can use one index.php (a front controller) to access them and centralize your setup stuffs there.


Jason, interesting to hear you're an Eclipse convert now . Mikalee: I can recommend that setup .

I'd like to note that IMHO Subclipse is indeed (still) the preffered tool to make Eclipse communicate with Subversion. I'd recently installed the newer Subversive, which is an official Eclipse project promising to offer the same and also claiming to be stable already. However, I found their tool to be buggy and far from ready for prime time. It made me feel VERY insecure having my data handled by Subversive. I've also posted back one of my problems on their support forum, but got completely ignored, which doesn't inspire confidence in their drive to complete their tool.

[Mikalee]

Thanks for the replies.

Gwaihir, at first I considered using a 'real' framework like Zend (though based on my research, symfony and cakephp were both preferred). But due to my specific requirements (that being that this is actually going to be a facebook application, not a stand alone php app), I started thinking I probably won't be making use of much of the frameworks and so it'll be adding unnecessary overhead.

At this point I'm thinking the main things I'm looking for are a DB abstraction layer and *maybe* something like the form creator (though I have to see how that'll work with the facebook api). I was also considering a template system, but based on the responses here I'm thinking I don't need it. The DB_DataObject package also sounds interesting, I will look into that as well. In the future, I may add more libraries (for things such as caching , and others I can't think of now), but I don't want to worry about that for now.

All that being said, I'm thinking it would be better for me to keep as lean as possible (by using only the packages I need from something like PEAR) as it may take more work to use the other frameworks for a facebook app. What do you think?

And thanks Jason, I will try that out.

Mike

[Gwaihir]

I don't think it matters in terms of 'lean' whether you take a DB abstraction solution from PEAR, or the one in the Zend framework, or AdoDB to name another one, one I've used to my satisfaction in the past. That's what I meant by the framework lending itself for using only what you need from it. However, personally, if you're not going for a prefab object-relational mapper, I would use PDO straight up, i.e. no DB abstraction layer at all.

PDO isn't an abstraction layer, as it doesn't sync the functionality across RBMSes, however it does provide a nice consistent interface (i.e. does away with all the the DB-specific function names). It also runs fast, as it is a PHP extension, not a set of scripts.


As for the templating. Good to hear you're in the camp that recognizes that PHP is a fine language for templating itself . Still, you'll want to seperate your display logic from your application logic and that means templates and thus a set of actions specifically concerned with handling those. Therefore, you might want to check out Savant. It's a templating system that strives to provide all the comfort and functionality of the popular and extensive Smarty, but WITHOUT the sillyness of introducing a new language that requires its own compile step, etc.

N.B. Though Savant would be my first choice, I've not yet seriously built on a project that allowed me to pick the template engine myself. Therefore I can't say I have extensive experience with Savant. I'd love to hear back about it if you give it a swing (even if you end up only evaluating it and finding fault with it in some way).


Jason: that local repository of yours, is that setup for PHP5? Another user posted here some weeks ago having trouble to get a PHP5 PEAR install in JagPCs dual PHP setup. It kept thinking it ran on PHP4, and thus wouldn't install PHP5 packages without being forced to.

[Mikalee]

Thanks Gwaihir, I will look into PDO and Savant and update this thread.