-- Andrea Turso <trashofmast...@gmail.com> wrote (on Tuesday, 01 December 2009, 03:22 PM +0100): > Hi everybody, it seems that this thread went quite off topic. > > I'm quite disappointed by the decision to discontinue the development > of a Data Mapper for the Zend Framework. I read this thread and agree > with most of the reasons against building a new one and waiting for > the release of Doctrine2. > > But AFAIK Doctrine2 is for PHP 5.3 hence excluding the great userbase > of the Zend Framework for PHP 5 could not benefit of a persistence api > for the Zend Framework. That's pity. It's not always possible to use > the cutting-edge release of PHP. Say Doctrine2 will be stable in 14 > months, do you think every hosting provider on the plan will have done > the leap to PHP 5.3 then? I don't think so. > > IMHO it's awful to discontinue this great project and wait for > Doctrine2 to be realeased and integrated with the Zend Framework, > there're people who need a Data Mapper now (me included!)
You're making several invalid assumptions. First, the Doctrine integration effort is happening *now*, and focusses on two separate integrations: one for the Doctrine 1 series, and one for the Doctrine 2 series. Doctrine 1.x works with PHP versions >= 5.2, and many, many folks are using it with ZF successfully already (myself included). If you search for blog posts that reference both ZF and Doctrine, you'll find several dozen out there. Second, Doctrine2 is currently in alpha status. My understanding is that they hope to have a stable release sometime in Q1 2010 (somebody correct me if I'm wrong). In addition, there are a number of frameworks moving towards PHP 5.3-only versions in the coming year: Symfony, Lithium, Agavi... and ZF itself, in version 2.0, will require 5.3 and above. Because so many projects will be adopting 5.3, there will be tremendous pressure on the part of hosting providers to make 5.3 a standard option. In fact, many Linux distributions and Mac OS X are shipping 5.3 as the default PHP version. I don't foresee this as a problem at all. This does not mean that you won't be able to continue using 1.x versions of ZF and Doctrine; they will continue to work, and be a fantastic combination for development. > I've been building a poor-man metadata mapper these days, it doesn't > implement the JSR220 specs but it works. You know, building a data > mapper is not my primary concern when working. > > By the way I'm a kind of abstraction addicted and quite bigot about > objects, so I started reading the JSR220 Java Persistent Api > specifications, but I don't want to clutter the simple data mapper > I've written, and instead spending my spare time implementing a JPA > compliant data mapper. > > I could try to continue developing what started by Benjamin. > > Just a side note: I know the Reflection API limitation for non-public > properties in PHP prior to 5.3, and I really don't want to break > encapsulation by using specific methods that must be inherited by > entities from a non domain-specific class. > > So I was wondering about using serialization to break the > encapsulation and retrieve properties value. Could it be a viable > solution? While I admire your enthusiasm to continue working on Zend_Entity, I would like you to consider giving Doctrine a try -- I'd start with 1.2.0. While it's not JPA compliant, it's more than usable, and much of what you learn with it will still be applicable later when you are able to adopt PHP 5.3 and Doctrine 2.0. If it still doesn't meet your needs, then the next step would be to build a _consortium_ of interested developers. We know from experience already that having a single developer on Zend_Entity is non-viable, and would take much too long to complete the project. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/
