Database abstraction, total OO refactoring, and more!!!

Some additional benefits:

* maintenance of the code will be easier as methods and properties associated with a specific database table will be grouped in one spot; no more special file for formatting template vars, or duplicating content; currently, logic associtiated with particular objects is spread throughout the system, so if I try to make a small change in one spot, I will likely break it somewhere else

* unit tests: the only way we’ll really be able to incorporate unit tests in a useful way, is using a solid OO framework such as this, as well as the build capabilities of Phing

* transaction support when used with DB’s that have transaction support

* cascading delete support, including emulation on DB’s that don’t support this (e.g. MySQL)

* automatic multiple object instantiation: when creating an object that has related classes (e.g. user_attributes is a child of user) you only have to instantiate the child object and the parent is automatically available from the child object (e.g. $ua= new UserAttributes(); $ua->getUser() )

* all extensions to the classes can be isolated in stub classes (or subclasses) and we can allow developers to extend or override the functionality of any core class without ever touching the core code; upgrades would be seemless with their custom code

* database enforced validation is included; and can be described directly in the XML schema used to generate the SQL scripts and object model

* LOB support via Creole, which allows things like saving images or other files to a DB and outputting directly from the database

* Date/Time support that is transparent across DB’s and generates values that respect the standard PHP date/time locale settings

* As database optimizations are made, code that uses the object model will not change

* we can automate the creation of database create/upgrade scripts directly from the XML schema using Phing and Creole, which are required parts of the Propel generator anyway

I could keep going, but... it may seem like a lot to absorb, but this is where I truly believe the project needs to go, and we can address the 5 classes issue; the Propel generator uses templates to generate the classes and I’ll be we can get it to generate all the required interfaces and abstract classes in one file, leaving only the concrete class separate for maintenance purposes. Additional overhead it might be, but the key here is a balance between modularity/extensibility and performance/simplicity. With a group of great developers like we already have assembled here, this would only make us more productive, able to collaborate more effectively, and provide a code base founded in standards that will make it easy to attract and incorporate quality OO developers into the project.

Thanks Jason... it sounds quite incredible when you put it that way. I’d definitely be willing to trade an ounce of performance for a pound of robustness, automated unit/regression testing, automated versioning, proper localization and so on... Nice stuff indeed. Can’t wait to see the proof of concept!

Hmmm,

Currently we have around 45 tables present in MODx. This would that propel would create 45x2 = 90 classes and if we add php 5 to that we have 90x2 = 180 classes.

Now what is we have say 10 widgets on a page that works on separate tables each? Then we would need 10*5=50 classes to get those widgets working.

IMO I don’t think we need to show developers core tables. They need to see the system as objects. That is to say they see the Users object, the Documents Object the Widgets Object, the Templates Object, etc.

I’m not for allowing developers to interact directly with the core tables. Developers should only interact with the core objects. This however does not mean that they are limited to the system.

I’m for using simple systems that’s why I started using with Etomite after dropping Typo3. I just could not bother with it’s complex systems.

If writing a snippet to get a document can’t be as simple as the Eto APIs then I think we have lost sight of the simple developer. While we would have attracted some of the OO guys we will certainly lost those who are not OO or can’t understand it.

IMO we can learn from Propel and create something that’s more specific and requires a less complex structures but offers the similar benefits.

Quote from: xwisdom at Dec 07, 2005, 03:33 PM

Currently we have around 45 tables present in MODx. This would that propel would create 45x2 = 90 classes and if we add php 5 to that we have 90x2 = 180 classes.

Not true, most of those tables will go away or, since many are cross-reference tables, though the tables wouldn’t go away, the objects would only be used/loaded in conjunction with the objects they are cross-referencing.

Quote from: xwisdom at Dec 07, 2005, 03:33 PM

Now what is we have say 10 widgets on a page that works on separate tables each? Then we would need 10*5=50 classes to get those widgets working.

Again, not true; widgets are one class of objects. This class structure is proven, accepted, and though to a procedural programmmer, may seem like overkill, absolutely necessary for the proper development of OO design patterns.

Quote from: xwisdom at Dec 07, 2005, 03:33 PM

IMO I don’t think we need to show developers core tables. They need to see the system as objects. That is to say they see the Users object, the Documents Object the Widgets Object, the Templates Object, etc.

That’s exactly what this does; I simply, for proof of concept reverse engineered the object model directly from the current data structure. And I’ve actually just completed rewritting the schema to follow a more proper object model despite the table structures, which I didn’t have to change at all (except for a few things that needed to be changed, like TINYINT with 1 or 0 possible values turned into BOOLEAN, and INTEGER fields storing UNIX timestamps to the TIMESTAMP type).

The classes are Documents, Templates, Users, Snippets, Chunks, Plugins, Modules, UserGroups, UserRoles, etc.

Quote from: xwisdom at Dec 07, 2005, 03:33 PM

I’m not for allowing developers to interact directly with the core tables. Developers should only interact with the core objects. This however does not mean that they are limited to the system.

That’s exactly what this system prevents. No one ever touches the tables, at all, even us!

Quote from: xwisdom at Dec 07, 2005, 03:33 PM

I’m for using simple systems that’s why I started using with Etomite after dropping Typo3. I just could not bother with it’s complex systems.

To me, this object model is very simple while still providing us flexibility. Nothing complicated about it at all, unless you just don’t understand object-oriented design.

Quote from: xwisdom at Dec 07, 2005, 03:33 PM

If writing a snippet to get a document can’t be as simple as the Eto APIs then I think we have lost sight of the simple developer. While we would have attracted some of the OO guys we will certainly lost those who are not OO or can’t understand it.

Simple developers is not a real thing. There are those that understand how to develop procedurally (mostly hackers and those that took a few programming courses in college) and those that understand how to develop OO (usually requires training in OO programming techiques and philosophies), and those that don’t understand either and simply copy what they see. I believe if people see the examples, it will be easier to follow that anything we have now. Code will be smaller, sleeker, and you’d never have to see another SQL query again, unless you wanted to manually to some custom table you need optimized outside of the abstraction layer.

Quote from: xwisdom at Dec 07, 2005, 03:33 PM

IMO we can learn from Propel and create something that’s more specific and requires a less complex structures but offers the similar benefits.

I disagree; it would take us years to completely understand the entire persistence framework, class generation techniques, and allowances for deploying to PHP4 and 5. This was developed by the guys who developed Apache Turbine, a similar framework for Java, and has the benefit of years of design and implementation efforts behind it.

Quote from: OpenGeek at Dec 07, 2005, 03:50 PM

Quote from: xwisdom at Dec 07, 2005, 03:33 PM

Now what is we have say 10 widgets on a page that works on separate tables each? Then we would need 10*5=50 classes to get those widgets working.

Again, not true; widgets are one class of objects.  This class structure is proven, accepted, and though to a procedural programmmer, may seem like overkill, absolutely necessary for the proper development of OO design patterns.

While we might lose some tables to redesign but as we continue to grow our number of tables will increase. What then?

In my response above I’m talking about 10 widgets, using the Documents (SiteContent) table, one working on the Users table, etc. Now that would make it ten tables right? How many objects would propel then require for these 10 tables?

Wouldn’t it make more sense to move this down to the Core Architecutre forum so more folks can comment on it (Jeff/Adam/Victor)?

Some other info:
http://www.oracle.com/technology/pub/articles/php_experts/futureofphp.html

Propel Propel is an object persistence and query framework. It implements object/relational mapping (ORM) and is based on the Apache Torque project, which does the same for Java. Unlike PDO, Propel is a very high-level database abstraction layer, redefining how you query, create, and manipulate persistent objects. Propel, as expected from an OO/RDBMS mapping system, also deals with database schema creation.

There are many advantages to a system like this. For starters, developers can concentrate most of their time on writing business logic and have to deal less with the intricacies of the database—whether it is schema management or writing fancy SQL statements. Database manipulation is very natural, as developers just deal with regular objects and the persistence layer deals with the low-level details of updating the right fields and rows in the database.

The disadvantage is that you do lose some control. The automatic mapping of the OO model to the relational database is not always straightforward. Not only does it make it hard to write fancy, powerful, hand-crafted queries, but you’re also not supposed to do so—you break the abstraction, and a tiny update of the mapping might break the application. Therefore, using such a system means you have to play by the rules of the tool. In most cases, this price is acceptable, as increased productivity helps shorten development times and improves code quality. However, there are certain instances where you might absolutely require this control.

Propel is a very interesting project and can come in handy. In addition, it is built on top of a database abstraction layer called Creole. Unlike PDO, this abstraction layer tries to mimic JDBC as much as possible and might be easier to use if you are converting existing Java code to PHP. That said, if PDO becomes mainstream and is distributed as part of standard PHP, it might be best to stick with that.

An interesting article that references PDO and also a bit of inside scoop on what’s going on with Zend’s Framework: http://shiflett.org/archive/168

In addition, they are abstracting Creole out of Propel, and you will be able to choose your data layer, be it Creole or PDO (or possibly others).

And +1 from me on moving this discussion to the core architecture forums.

While we might lose some tables to redesign but as we continue to grow our number of tables will increase. What then?

In my response above I’m talking about 10 widgets, using the Documents (SiteContent) table, one working on the Users table, etc. Now that would make it ten tables right? How many objects would propel then require for these 10 tables?

@Raymond --> again, this is only loading the class files once for each type of object you want to instantiate, so if you instantiate ten widget instances, then yes, there are ten objects loaded, but only one Widget class (or two if you extend the Widget class to be of snippet or plugin variety, or however we choose to go with that). But again once per class. Then the instances reuse the class definition in the PHP scripting engine. The overhead is actually quite minimal, especially in PHP 5. I have not tried the PHP 4 runtime yet.

Here’s another user’s experience on Propel:

http://revjim.dreamhosters.com/articles/2004/11/04/propel-parte-deux