I'm starting with CodeIgniter and after several hours diving in Google I'm a bit confused.
Let's try to explain my question with a easy example: I have a table 'car' with the fields 'name' and 'color'. Therefore I want to have a php class Car, so that my code could look finally like this:
$car = new Car('BMW', 'red'); //new $car Object
$car->save(); //this will make an SQL insert to the table 'car'
//Lets query all cars
$cars = Car::get_all();
//cars will be an array of Car objects, (not a set of rows!)
Therefore, I am looking for something pretty similar to what you have in RubyOnRails or Django (Python). I need to handle all kind of relationships, and to be able of write code in a true OOP+MVC way.
These are my failed approaches to get it:
Using an external ORM (DataMapper, Doctrine, AcidCrud...)
They either requires too many settings, or they handle relationships in a poor way.
Using CodeIgniter classes (to extend the CodeIgniter's Model class)
class Car extends Model{
public function Car($name='',$color='')
{
$this->name = $name;
$this->color = $color;
parent::Model();
}
public function save()
{
$data = array(
'name' => $this->name ,
'color' => $this->color
);
$this->db->insert('cars' $data);
}
And so on... Problem with this approach is that if a do a var_dump() of a $car object, I see that it contains a lot of stuff from the CodeIgniter, such as the objects CI_Config, CI_Input, CI_Benchmark, etc. Therefore I think this is not a good solution, because each object of my class Car, it will contain a lot of repeated data, (it will have a poor performance!), isn't it?
Not using the CodeIgniter's models
I could make my models without extending them from CodeIgniter's Model class, and then using the regular PHP5 constructor (__construct() instead of function Car()), but problem in this case is: how I access to the $db object to make querys using the CodeIgniter's ActiveRecord? and, how I load the models (its classes) within the controllers?
You probably want something like this:
class Cars {
//List all neccessary vars here
function __construct() {
//get instance of Codeigniter Object and load database library
$this->obj =& get_instance();
$this->obj->load->database();
}
//You can now list methods like so:
function selectCar($name, $color) {
$this->obj->db->select('color')->from('car')->where('color', $color);
$query = $this->obj->db->get();
switch ($query->num_rows()) {
case 0:
return false;
break;
default:
return $query->result();
break;
}
}
Hope that helps!
Try with Doctrine, is a great ORM and can be easily integrated in CodeIgniter.
take a look the the codeigniter wiki page for ORM
http://codeigniter.com/wiki/ORM/
For future Googlers, here is a tutorial I wrote up about how to integrate CodeIgniter 2 with Doctrine 2.
Let me know if you have any issues.
I had good luck with using Propel with codeigniter.
check out GAS ORM it sounds pretty good, handy and easy to use.
some features of this ORM implementation for CodeIgniter:
Supported databases : cubrid, mssql, mysql, oci8, odbc, postgre, sqlite, sqlsrv. (including PDO, if you keep sync with CI repo)
Support multiple database connections.
Support multiple relationships.
Support composite keys (for key that define relationships).
Auto-create models from database tables and vice versa.
Auto-synchronize models-tables by creating migrations file.
Per-request caching.
Self-referential and adjacency column/data (hierarchical data).
Eager Loading to maximize your relationship queries (for performance manner).
Various finder methods (can chained with most of CI AR) and aggregates.
Validation and auto-mapping input collection with minimal setup.
Hooks points to control over your model.
Extensions to share your common function/library across your model.
Transactions and other CI AR goodness.
Included phpunit test suite to ensure most of API consistency.
there is one form with spark support -> so it's easy to install
What you want to do is create a library that extends the ActiveRecord class. Some people are ahead of you:
http://codeigniter.com/wiki/ActiveRecord_Class/
good mods in the thread, here:
http://codeigniter.com/forums/viewthread/101987/
If you're looking for ORM methods that are general to your app, just extend the ActiveRecord class. For my application, knowing the structure of a table allows me to scaffold (auto-generate) forms, and do other mapping. I do API-to-API mapping, so I include a GetStructure() method in MyActiveRecord and build other things from there.
(RoR snickering can bugger off now)
Edit: while I am a fan of the scope and power of Doctrine, I think it's demand for command-line usage places it beyond the spirit of CI. What's right for you is what's right for you, but if I'm going to use Doctrine, I might as well use Symfony, right? Or RoR, for that matter, right?? See where I'm gong with this? Right tool for the right time.
I used CodeIgniter with Propel and they really mixed well. I've used like that for a while and got a few webapps working that way. Since I found a few awful ways to do it ( some included modifiying Apache's configuration!!). I decided to publish a blog post on how to do it. You can read it here.
Hope I can help!
I think php-activerecord is a very good drop-in ORM. I've used it with the Slim Framework a few times and I think it would be a great alternative to using CI's native model class. Here is some sample code and the link:
$post = new Post();
$post->title = 'My first blog post!!';
$post->author_id = 5;
$post->save();
PHP ActiveRecord
i know this is quite old, but for those who are just using codeigniter now and wannt to use an orm with it can use this tutorial to integrate propel with codeigniter
http://llanalewis.blogspot.com/2013/06/installing-propel-in-codeigniter.html
Related
I've been working on a project and I decided it'd be a good idea to have some sort of, like, DAO, but simplified.
Basically, the only thing I want from it (right now, at least) is to fetch me objects by model name and id. I wrote this very simple piece of code:
class DAO {
public static function get($className,$id) {
$queryName = $className."Query";
if (!class_exists($className) || !class_exists($queryName)) {
return false;
}
$q = $queryName::create()->filterByID($id)->find();
return $q;
}
}
However, I found myself stuck with the implementation. I guess I need to somehow autoload it so that it'll be able to check for the existence of the classes and so that I could use it anywhere inside my app, but I don't know how. Can anyone help me out? Or if there's a better way to do that, I'll appreciate any input.
What you're looking for is a Service.
Definition from the documentation:
Put simply, a Service is any PHP object that performs some sort of
"global" task. It's a purposefully-generic name used in computer
science to describe an object that's created for a specific purpose
(e.g. delivering emails). Each service is used throughout your
application whenever you need the specific functionality it provides.
Defining your class as a service is as simple as this:
app/config/config.yml
...
services:
my_dao:
class: Your\Bundle\DAO
...
Now you can access DAO in your controllers doing something like this:
$dao = $this->get('my_dao');
When you make this call, the Service Container will create an instance of your class and return it. There will always be at most one instance (singleton) and if it's never called, it won't even be instantiated.
I recommend reading the documentation.
Opinion
It seems like you're having trouble adapting to the Symfony way.
If you take a look at The Book you'll see that the Entity Manager in conjunction with your entity's Repository handle most of what DAO's traditionally did. In other words, there's really no need for your DAO class.
For example, fetching any object by id is as easy as:
$om->getRepository('YourBundle:YourModel')->find($id);
Anyway, if you're particularly fond of that approach, you may want to try this project.
I'm trying to decide on something, where to put database logic, in the controller or model when using the eloquent orm.
In a controller I have the following method:
public function postAdd(){
$amodel=new myModel();
$amodel->name=Input::get('name');
$amodel->save();
$id=$amodel->id;
}
Which is how the guides say to use it however should this logic not go inside a method on the model rather than in the controller? I know the above still provides abstraction from the database but the bit that I'm unsure of is how reusable it then becomes... or not as the case maybe.
Would it therefore be a better option to do the following:
public function postAdd(){
$amodel=new myModel();
$id = $amodel->addPost(Input::get('name'));
}
So I pass along information to a method on the model which does the work. This allows it to be reused and the model method changed if required without updating many lines of code?
The answer might simply be 'yes, do it like you've suggested' in which case great but I'd be interested on the standard practice when using an ORM like this.
A controller's sole responsibility is handling and delegating UI requests to the Model. That's why it should be skinny. It should only contain code necessary for what it's responsible for. So thats why you should move your code to the model, or, even better and more Laravel-like solution is to use repositories in this case. (link)
Is there a PHP framework, that lets me write such code.
class Item
{
private $_id; //primary key
private $name;
private $price;
function __construct($name, $price) {
$this->name = $name;
$this->price = $price;
}
}
...
$item = new Item(...);
db->Save($item);
...
db->Delete($item);
...
db->Update($item);
...
Item[] = db->Fetch($whereClause);
Yes Admins, I searched on Google, but I got lost in the vast sea (Doctrine, Propel, ActiveRecords,...), asked a different question on SO (which prohibited me from comparison), so I am asking differently now, which framework lets me write such simple code, without much additional coding, no XML, YAML.
Or additionally how to write such if not there. Any pointers will be helpful. Off course I have PHP 5.3 and can use PDO, but performance is a concern (magic functions...), not extensive features list (we support this thing also, that you will never use).
OOPS: forgot to add, don't want a framework like CakePHP, etc. I am writing simple php without frameworks, want just some libraries that I can include into my project and call the above syntax. Its ok for me, if it requires a little SQL behind.
If you do not need a full application framework, for example, you might have written your own framework or if you are not using any framework, I can not recommend Redbean enough. On the plus side, Redbean also has bridges for frameworks such as Zend and CodeIgniter.
I like Redbean because it does not require much configuraion, no YAML, XML or other configuration. The library is very light and quite performant. The amount of features is about "just right", there are no superfluous features, but you do have all the things you need in there. The syntax is also very close to the one you want.
Now the downside: You need to adhere to strict table structures. For example, an ID column is need for link tables. Support for table name prefixes has also been removed in 3.0. However, I don't find these things to be important, so it isn't a huge issue for me.
If it is, you could even fork the library and modify it to your needs.
php-activerecord will probably fit your needs. Model classes should extend from ActiveRecord\Model:
<?php
class City extends ActiveRecord\Model {
// Table name will be defaulted to 'cities', but you can override it
static $table_name = 'mycities';
// Primary key will be defaulted to 'id', you can override it too
static $primary_key = 'city_id';
// Associations
static $belongs_to = array(
array('country')
);
static $has_many = array(
array('citizens', 'class_name' => 'User')
);
}
// Creating
$city = new City(array('name' => 'New York'));
$city->save();
// Find City with id=5, output some data
$anotherCity = City::find(5);
echo $anotherCity->country->location;
foreach ($anotherCity->citizens as $citizen) {
echo $citizen->full_name;
}
This is a very simple example, php-activerecord has some nice features:
Sensible conventions, you can reduce amount of code by following them (in fact, you should follow them if you're starting from scratch)
Validations to enforce business rules
CRUD for manipulating objects in OO-way
Callbacks - advanced pieces of code to associate with different lifetime events of your models
I think a lot of them. ZendFramework is one of such frameworks.
cake PHP is very near to your requirement
search scfolding with cake PHP is very near to your requirement
Thanks
There are many frameworks. See this for an example.
Every frameworks have there own way of API, through which you can use many features, such as db, xml.
For ORM only Doctrine is very Excellent
For rapid development and scaffolding features Codeigniter is very good.
For in-depth framework with many pre-built libraries Zend-Framework is one of the best. It has libraries for Doctrine too.
I am trying to learn OOP. The so called 'real world' examples in the books I am reading aren't helping.
All the examples like Pet, Car, Human aren't helping me anymore. I need REAL LIFE examples that like registration, user profile pages, etc.
An example:
$user->userName = $_POST['userName'];//save username
$user->password = $_POST['password'];//save password
$user->saveUser();//insert in database
I've also seen:
$user->user = (array) $_POST;
where :
private $user = array();
Holds all the information in an array.
And within that same class lies
$user->getUser($uid);
// which sets the $this->user array equal to mysqli_fetch_assoc() using
//the user id.
Are there any real world examples implementing OOP in the many different php applications (registration, login, user account, etc)?
OOP is not only about how a single class looks and operates. It's also about how instances of one or more classes work together.
That's why you see so many examples based on "Cars" and "People" because they actually do a really good job of illustrating this principle.
In my opinion, the most important lessons in OOP are encapsulation and polymorphism.
Encapsulation: Coupling data and the logic which acts on that data together in a concise, logical manner
Polymorphism: The ability for one object to look-like and/or behave-like another.
A good real-world example of this would be something like a directory iterator. Where is this directory? Maybe it's a local folder, maybe it's remote like an FTP server. Who knows!
Here's a basic class tree that demonstrates encapsulation:
<?php
interface DirectoryIteratorInterface
{
/**
* #return \Traversable|array
*/
public function listDirs();
}
abstract class AbstractDirectoryIterator implements DirectoryIteratorInterface
{
protected $root;
public function __construct($root)
{
$this->root = $root;
}
}
class LocalDirectoryIterator extends AbstractDirectoryIterator
{
public function listDirs()
{
// logic to get the current directory nodes and return them
}
}
class FtpDirectoryIterator extends AbstractDirectoryIterator
{
public function listDirs()
{
// logic to get the current directory nodes and return them
}
}
Each class/object is responsible for its own method of retrieving a directory listing. The data (variables) are coupled to the logic (class functions i.e, methods) that use the data.
But the story is not over - remember how I said OOP is about how instances of classes work together, and not any single class or object?
Ok, so let's do something with this data - print it to the screen? Sure. But how? HTML? Plain-text? RSS? Let's address that.
<?php
interface DirectoryRendererInterface
{
public function render();
}
abstract class AbstractDirectoryRenderer implements DirectoryRendererInterface
{
protected $iterator;
public function __construct(DirectoryIteratorInterface $iterator)
{
$this->iterator = $iterator;
}
public function render()
{
$dirs = $this->iterator->listDirs();
foreach ($dirs as $dir) {
$this->renderDirectory($dir);
}
}
abstract protected function renderDirectory($directory);
}
class PlainTextDirectoryRenderer extends AbstractDirectoryRenderer
{
protected function renderDirectory($directory)
{
echo $directory, "\n";
}
}
class HtmlDirectoryRenderer extends AbstractDirectoryRenderer
{
protected function renderDirectory($directory)
{
echo $directory, "<br>";
}
}
Ok, now we have a couple class trees for traversing and rendering directory lists. How do we use them?
// Print a remote directory as HTML
$data = new HtmlDirectoryRenderer(
new FtpDirectoryIterator('ftp://example.com/path')
);
$data->render();
// Print a local directory a plain text
$data = new PlainTextDirectoryRenderer(
new LocalDirectoryIterator('/home/pbailey')
);
$data->render();
Now, I know what you're thinking, "But Peter, I don't need these big class trees to do this!" but if you think that then you're missing the point, much like I suspect you have been with the "Car" and "People" examples. Don't focus on the minutiae of the example - instead try to understand what's happening here.
We've created two class trees where one (*DirectoryRenderer) uses the other (*DirectoryIterator) in an expected way - this is often referred to as a contract. An instance of *DirectoryRenderer doesn't care which type of instance of *DirectoryIterator it receives, nor do instances of *DirectoryIterator care about how they're being rendered.
Why? Because we've designed them that way. They just plug into each other and work. This is OOP in action.
Purchase a book like "PHP and Mysql everyday apps for Dummies".
Its old I know [2005] but it shows concepts of User Logins, Forum, Shopping Carts, etc in both Procedural and Object Oriented with Mysqli.
It helped me learn Object Oriented PHP, I studied it a lot. Well worth the money.
OOP is much like grouping bits of your program into reuseable pieces. Its not that hard to be honest with you its just the idea of packing your functions into classes.
Real world mini example of OOP stuff below:
CLASS DATABASE
CLASS SESSIONS
CLASS WEBFORMS
CLASS EMAIL
CLASS ACCOUNTS (Example Functions below)
FUNCTION SELECTACCOUNT
FUNCTION CHECKPASSWORD
FUNCTION CHECKUSERNAME
FUNCTION CREATEACCOUNT
I hope you keep at it, PHP 6 will be re-engineered to support OOP more than ever.
Good Luck!
Whilst I know that this question has been answered already, I feel as though I can add value here.
I don't believe that you should use PHP as a programming language to learn OOP. If you wish to learn OOP for web applications, you should really be looking at C# or Java. Once you have learned OOP, then you can apply this knowledge to PHP. One example of a book I used to learn OOP was Big Java by Cay S. Horstmann
Why do I say this??? Because there are literally millions of examples on PHP of how to do stuff, however not many are examples of how to program properly. Further to this, PHP allows you to take many shortcuts, which would not be acceptable with the likes of Java. As such, if you program PHP with a Java head, then I believe that you will be a stronger programmer. OOP is not language specific, it is a programming paradigm.
If you must learn OOP using PHP, then I would recommend that you take a look at some real source code in public repositories of github. You can search them in packagist.org. If they are a decent public repository, they will contain a readme.md file which would show you how to use the composer packages. e.g https://github.com/moltin/laravel-cart is an example of a shopping cart package which you would be able to use in your application. Notice how you don't need to look at the package source code to understand what the packages do. The package has been written, and you don't care about how they work, but you use them so you only need to know how to use them. This is exactly what OOP is about.
I don't care how the shopping cart class adds an item to the cart, I just want to create a new cart and add something to it.
What you are doing however is diving into the source code as a tool to understand how OOP works.
Further to this, and probably more importantly, for web application development, I would research the MVC design pattern.
The MVC design Pattern stands for Model, View, Controller. Where in the case of a web application, The Model is responsible for modelling the database, the view is responsible for displaying content to the user. The controller is responsible for interacting with the model and handling user input.
I then think you should try to install the Laravel Framework or other "decent modern framework" on your local machine. Why do I say modern, because modern frameworks require a minumum PHP version of 5.3+ which mean that the PHP on your machine would support real OOP similar to that which you would get from the likes of Java.
There are many tutorials which will show you how to build web applications in laravel. Immediately, you will see that when you create a controller, you extend a BaseController. When you create a Model, you extend Eloquent. This means that you will already be using Polymorphism in your code. You will see that by using classes, they are being encapsulated, and you will see that each class has a specific role.
When you would like to interact with the database, you will initially create a new Model object within the controller methods. As you start to learn more, you will start learning how to inject dependencies into the controller, then learning how to dump your models and create repositories and program to interfaces instead.
A decent book on learning Laravel for beginners would be https://leanpub.com/codebright by Dale Rees. I met Dale at a Laravel meetup about 2 weeks ago.
Further to this, as you become more proficient building web applications, you will start to learn how to apply the following principles to your programming:
Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segragation Principle
Dependency Inversion Principle
As astropanic said, you could take a look at the source code of a good PHP framework or library. I recommend Zend Framework, it's very modular and has a great, professional design. I would say it is a very good piece of object-oriented PHP code.
Still, I think it's not that easy to learn from a huge piece of production code, since it wasn't really made to teach you anything. But if you want real-world object-oriented PHP code, the Zend Framework (or Symfony, or maybe CakePHP) is probably the way to go.
I'd advise you to stay away from any framework at this moment, if you do not know OOP, digging into zend or any other framework would be too much.
PHP OOP is quit funny... like ha ha funny, because it's supported, but PHP is not an OOP language like java or c#.
Short example just to underline my statement:
// define class
class User {
// define properties and methods
public $name = "";
}
// instantiate class
$user = new User; // or new User() or new user, it's all the same
echo $user->name;
but if you want to do OOP "on the fly" you can do the following:
$user = (object) array('name' => 'Peter');
and then
$user->name;
but you can use OOP like you would in java or c# but not to the same extend - and have in mind, popular systems like wordpress and drupal are not pure OOP! but you can do inheritance and other classing OOP stuff in PHP as well.
I haven't gone far in PHP OOP, but the more i get into it the more easier it becomes. The objects examples are just there for you to understand how OOP works. I understand and been through this before, OOP is just about properties and methods ( normal variables and functions). I programed in real OOP myself applying the examples from my tutorials and didn't necessarily have to be in real world. That is just like been spoon fed and you would never understand OOP and would be easy to forget. My advice learn to understand. If you understand, you can do anything and would realize the power of OOP. I downloaded this book and i think you should too. But that is just like someone building your apps for you...
Here a link to the book PHP and Mysql everyday Apps For Dummies
you're right 99% of the tutorials that you'll find online are too basic, and they don't make sense. My suggestion to anybody trying to learn object oriented programming is:
find some code that you've written in procedural programming and try to convert it into OOP.
Take all your variables and make them a properties of a class, find a suitable class name. Then take all your functions, if you have functions, and group them within a class. If you wrote your code without using functions, first try to convert your code into a group of functions. find suitable function names, a function should define what a piece of code does. Once you have your functions move them into a class.
I'll give you a simple example of a pagination code that I converted into a reusable pagination class. find the full tutorial on youtube: https://www.youtube.com/watch?v=X38IRlyY_ww&t=91s , link to the source code is on the description box
class Paginator{
/*the class need to know the current page to calculate the offset
the offset tell my sql how many rows to skip */
private $current_page;
//the limit is the number of results to display per page
private $limit;
/*pagination links to display below the results with next
and previous button*/
private $pagination_links;
//the last page of your pagination links
private $last_page;
.
. etc
public function __contruct($number_of_rows_found,$results_to_display_per_page){
//the paginator uses the number_of_rows_found to determine the last page
$this->last_page = $number_of_rows_found/$results_to_display_per_page;
//get the current page, set it to 1 by default
$this->current_page = isset($_GET['page']) ? ($_GET['page'] : 1;
}
public function generate_pagination_links(){
this method uses the last_page property to generate pagination links
if the last page is 3, this will give you 3 pagination links
for ($page = 1; $page <= $this->last_page; $page++) {
//use
}
}
public function get_offset_and_limit(){
//this method calculates the offset based on the current page
return "LIMIT $this->per_page OFFSET ".($this->page - 1) * $this->per_page;
}
.
.
.etc
}
}
Then to use the pagination class, you create a new instance of it, and pass the
number of results you want to display per page, and the the number of results returned
by your query as parameters. The pagination class will generate pagination links for
you and calculate the offset and limit. That's a good example of a php reusable
class, you can use it in your multiple projects without having to rewrite or change it.
$paginator = New Paginator($rows_found,8);
$pagination_links = $paginator->get_pagination_links();
$offset_and_limit = $paginator->get_offset_and_limit();
//apend the limit and offset to your sql query
$query = $query. ' '.$offset_and_limit;
$connection = getdbconnection();
$stmt = $connection->prepare($query);
$stmt->execute();
$movies = $stmt->fetchAll();
Ofcourse there're more advanced concepts into OOP that are not covered in this example, but this should give you a basic understanding of how classes and objects work
I suggest also to see my wrapper Arrayzy. It's a native PHP arrays easy manipulation library in OOP way.
So if you work with native PHP array functions - you could do the same things in OOP and Arrayzy helps you with it, for example:
// Functional programming:
$array = ['a', 'b', 'c'];
$resultArray = array_merge($array, ['c', 'd']);
and
// Object-oriented programming:
$obj = Arrayzy\MutableArray::create(['a', 'b', 'c']);
$obj->mergeWith(['c', 'd']);
$resultArray = $obj->toArray();
In both cases the result array will be:
Array(
0 => 'a'
1 => 'b'
2 => 'c'
3 => 'c'
4 => 'd'
)
Check how does this mergeWith method (or other) works under the hood.
I think this is a nice example which shows that almost everything functional code you could replace with OOP code like in this library. But with OOP you get much more and you could also check Functional programming vs OOP question to learn more details what's a cons and props of it.
I'm creating an ORM in PHP, and I've got a class 'ORM' which basically creates an object corresponding to a database table (I'm aiming for similar to/same functionality as an ActiveRecord pattern.) ORM itself extends 'Database', which sets up the database connection.
So, I can call: $c = new Customer();
$c->name = 'John Smith';
$c->save();
The ORM class provides this functionality (sets up the class properties, provides save(), find(), findAll() etc. methods), and Customer extends ORM. However, in the future I may be wanting to add extra public methods to Customer (or any other model I create), so should this be extending ORM or not?
I know I haven't provided much information here, but hopefully this is understandable on a vague explanation, as opposed to posting up 300+ lines of code.
I agree with the other answers here - put the additional methods into a descendant class. I'd also add an asterisk to that though: each time you extend the class with extra methods, think about what you are trying to achieve with the extension, and think about whether or not it can be generalised and worked back into the parent class. For example:
// Customer.class.php
function getByName($name) {
// SELECT * FROM `customer` WHERE `name` = $name
}
// ** this could instead be written as: **
// ORM.class.php
function getByField($field, $value) {
// SELECT * FROM `$this->table` WHERE `$field` = $value
}
You're certainly thinking correctly to put your business logic in a new class outside your 'ORM'. For me, instead simply extending the ORM-class, I'd rather encapsulate it with a new, value object class to provide an additional degree of freedom from your database design to free you up to think of the class as a pure business object.
Nope. You should use composition instead of inheritance. See the following example:
class Customer {
public $name;
public function save() {
$orm = new ORM('customers', 'id'); // table name and primary key
$orm->name = $this->name;
$orm->save();
}
}
And ORM class should not extend Database. Composition again is best suited in this use case.
Yes, place your business logic in a descendant class. This is a very common pattern seen in most Data Access Layers generation frameworks.
You should absolutely extend the ORM class. Different things should be objects of different classes. Customers are very different from Products, and to support both in a single ORM class would be unneeded bloat and completely defeat the purpose of OOP.
Another nice thing to do is to add hooks for before save, after save, etc. These give you more flexibility as your ORM extending classes become more diverse.
Given my limited knowledge of PHP I'm not sure if this is related, but if you're trying to create many business objects this might be an incredibly time consuming process. Perhaps you should consider frameworks such as CakePHP and others like it. This is nice if you're still in the process of creating your business logic.
You're definitely thinking along the right lines with inheritance here.
If you're building an ORM just for the sake of building one (or because you don't like the way others handle things) than go for it, otherwise you might look at a prebuilt ORM that can generate most of your code straight from your database schema. It'll save you boatloads of time. CoughPHP is currently my favorite.
I have solved it like this in my Pork.dbObject. Make sure to check it out and snag some of the braincrunching I already did :P
class Poll extends dbObject // dbObject is my ORM. Poll can extend it so it gets all properties.
{
function __construct($ID=false)
{
$this->__setupDatabase('polls', // db table
array('ID_Poll' => 'ID', // db field => object property
'strPollQuestion' => 'strpollquestion',
'datPublished' => 'datpublished',
'datCloseDate' => 'datclosedate',
'enmClosed' => 'enmclosed',
'enmGoedgekeurd' => 'enmgoedgekeurd'),
'ID_Poll', // primary db key
$ID); // primary key value
$this->addRelation('Pollitem'); //Connect PollItem to Poll 1;1
$this->addRelation('Pollvote', 'PollUser'); // connect pollVote via PollUser (many:many)
}
function Display()
{
// do your displayíng for poll here:
$pollItems = $this->Find("PollItem"); // find all poll items
$alreadyvoted = $this->Find("PollVote", array("IP"=>$_SERVER['REMOTE_ADDR'])); // find all votes for current ip
}
Note that this way, any database or ORM functionality is abstracted away from the Poll object. It doesn't need to know. Just the setupdatabase to hook up the fields / mappings. and the addRelation to hook up the relations to other dbObjects.
Also, even the dbObject class doesn't know much about SQL. Select / join queries are built by a special QueryBuilder object.