I totally agree with the points that Stephen has raised. I also appreciate the response that Mark has presented.
I personally took the approach of integrating Propel into my CakePHP application. Now, I have the flexibility to use Propel or array-based method. As Stephen suggested, I stick to array-based when I use components or logic that integrates into Cake's core. For my application specific logic, I find it more effective and cleaner to use the Propel approach. Here is a post that I wrote for anyone who is interested in using Propel with CakePHP: http://blog.anas-mughal.com/?p=48 Hope you find this approach useful. I welcome any comments. Best Regards. -- Anas Mughal http://anas-mughal.com On Tue, Jul 5, 2011 at 11:06 AM, stephenrs <ssgro...@gmail.com> wrote: > Thanks for your reply, Mark. I'd just chime in by agreeing that it is hard > to build an ORM...but since this wheel has already been invented..and > reinvented, it's hard to justify why a new ORM would need to be built for > Cake. There are already several mature PHP-based ORM systems (Doctrine and > Propel leading the pack) that are ripe for straightforward integration into > larger systems. > > So, rather than a backwards-compatibility-killing overhaul of Cake's model > system, perhaps a better approach would be to start by offering Cake > developers a choice by allowing the data access layer to be toggled between > returning the traditional arrays and returning objects via an existing ORM > that has been plugged in. Maybe this toggle could even be set application- > or controller-wide via the configuration system, or at run time for more > granular control. Doctrine offers this toggle out of the box, for example. > > This way, developers have a choice to migrate all, some, or none of an > existing application to an object oriented model system. Maybe there's > something about Cake's design that would make even this kind of architecture > unfeasibly difficult, but based on my (admittedly rusty) understanding of > Cake's internals, it shouldn't be too bad. Core system components could > transparently continue to use the array access method as long as they needed > to, and userland code could break free of arrays if it wanted to. > > Having been away for a few years, I'm actually a bit amazed (and > disappointed) that the 2.0 release isn't being used as an opportunity to > bring Cake more fully into the world of OOP. I'm not one to complain about > open source software though...I have much to be thankful for. > > > -SS > > -- > Our newest site for the community: CakePHP Video Tutorials > http://tv.cakephp.org > Check out the new CakePHP Questions site http://ask.cakephp.org and help > others with their CakePHP related questions. > > > To unsubscribe from this group, send email to > cake-php+unsubscr...@googlegroups.com For more options, visit this group > at http://groups.google.com/group/cake-php > -- Anas Mughal -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
