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!) 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? Andrea
