There isn't anything stopping you from using Doctrine or Propel now if you feel not having them is a huge loss. Other parts of cake loose some of the integrated features, but it can be made to work. The loss of integration is another reason that we haven't moved to another ORM, we'd either have to couple with that ORM which is simliar to where we are now. Or loose many of the features in cake that people like. Things like var $uses = array(...); don't work without layers of adapters and configuration when the models could come from a variety of providers. Perhaps integrating with Doctrine, PHPActiveRecord or Propel would be the best option in the future. I'm not sure, I haven't done the research and haven't evaluated the options versus rolling an update to cake's models.
As for things not changing in 2.0, we decided that revamping parts of the framework that needed php4 support removed, and switching the models all at once would probably create a huge time gap between releases and was something we want to avoid. Sorry that we couldn't better live up to your expectations. -Mark On Jul 5, 2:06 pm, 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
