Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
> 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. Yep, I knew that you're actively working on integrating Doctrine 1 in the ZF. I've been using Doctrine 1 for a while but it didn't meet my needs. As I said I tend to be a object bigot and to avoid dependency of the domain model upon other layers of the application. > 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. Okay, this would be great. Maybe this time hosting providers will migrate to the newer version of PHP sooner. > 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. Okay. By the way I think I'll start using PHP 5.3 and get started with Doctrine 2 Alpha. Andrea
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- Andrea Turso 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/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
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
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
> > One such area is unit testing; it's far easier to test a plain old PHP object than it is to test something that has couplings to the database -- which is what happens when your entities extend from a base class. This. Also because Doctrine is established, has many users and wide acceptance, the backing of a company, and a compatible license. We currently use it where I work, and while I have many issues with it, 2.0 will probably fix most of them. (I probably won't get a chance to use it, however; we're switching to Java EE for technical and staffing reasons.) -Matt On Wed, Nov 25, 2009 at 7:09 AM, Matthew Weier O'Phinney wrote: > -- Arié Bénichou wrote > (on Wednesday, 25 November 2009, 03:21 AM -0800): > > Reading the > > http://www.doctrine-project.org/blog/php-5-3-and-doctrine-2-0-teaser > > doctrine 2.0 teaser , I noticed that Doctrine planned to eliminate the > > need for an entity to extend from a base class. Althought, it sounds > > like writing an entity class is a little bit easier, since it can be > > any plain old php object, the reasons were not given. Then you said, a > > such base class is the root of all evils... Could you please, explain > > the difficulties you faced with entities having to extend a base > > class? > > One such area is unit testing; it's far easier to test a plain old PHP > object than it is to test something that has couplings to the database > -- which is what happens when your entities extend from a base class. > ORM's are supposed to remove such couplings, not introduce them. > > > > beberlei wrote: > > > > > > > > > Hello, > > > > > > Its not a failure to recognize that a proposal generates lots of > > > "duplicate > > > code", which is currently better solved in other projects. This also > > > has nothing to do with Zend, since the component was approved > > > under the premise that its community contributed. An ORM is a huge > > > undertaking and it creates lots of code that has to be maintained > > > and I as a community member decided that its probably not doable. > > > > > > Xyster ORM maybe existing for some time, however i haven't seen it in > > > use. Additionally although they claim not be ActiveRecord you have > > > to extend a certain base class for your entities to work with it. > > > This is the root of all evil in ORMs and the reason why enterprise > > > ORMs don't require it. > > > > > > The lead developer of Doctrine is indeed paid by SensioLabs, however > > > the Source Code is under the LGPL, which is a perfectly compatible > > > license with New BSD and doesn't restrict the use of the code. > > > There is also no effort whatsoever by SensioLabs to control Doctrine. > > > > > > Looking at it the other way, Doctrine is already several years old, > > > plus it benefits from lots of experience of the PEAR MDB2 component > > > aswell as others (eZ Components, ZF). The code basis is pretty robust > > > and there are people working on its perfection full time, which makes > > > it a pretty good choice for Enterprises. > > > > > > Going for Integration with Doctrine in my opinion is one step further > > > to professionaling php as an enterprise language. The different PHP > > > communities where cooking their own soups for the last 10 years. > Although > > > I like competition very much, one should also make rational decisions > > > when it is better not to reinvent the wheel. > > > > > > greetings, > > > Benjamin > > > > > > On Wed, 25 Nov 2009 00:51:38 -0800 (PST), Arié Bénichou > > > wrote: > > >> I don't understand why you did not use http://xyster.libreworks.net/ > > >> Xyster > > >> ORM > > >> It makes use of the Data Mapper Pattern and comes with a Unit of Work. > > >> Doctrine is shifting to this approach for the version 2.0, but it's > still > > >> an > > >> alpha release. > > >> It's a pity for you to have failed this way, because, Doctrine is > > >> associated > > >> to SensioLabs, the french agency who developps the Symfony Framework. > > > > > > > > > > -- > > View this message in context: > http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787474.html > > Sent from the Zend Framework mailing list archive at Nabble.com. > > > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ >
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- Arié Bénichou wrote (on Wednesday, 25 November 2009, 03:21 AM -0800): > Reading the > http://www.doctrine-project.org/blog/php-5-3-and-doctrine-2-0-teaser > doctrine 2.0 teaser , I noticed that Doctrine planned to eliminate the > need for an entity to extend from a base class. Althought, it sounds > like writing an entity class is a little bit easier, since it can be > any plain old php object, the reasons were not given. Then you said, a > such base class is the root of all evils... Could you please, explain > the difficulties you faced with entities having to extend a base > class? One such area is unit testing; it's far easier to test a plain old PHP object than it is to test something that has couplings to the database -- which is what happens when your entities extend from a base class. ORM's are supposed to remove such couplings, not introduce them. > beberlei wrote: > > > > > > Hello, > > > > Its not a failure to recognize that a proposal generates lots of > > "duplicate > > code", which is currently better solved in other projects. This also > > has nothing to do with Zend, since the component was approved > > under the premise that its community contributed. An ORM is a huge > > undertaking and it creates lots of code that has to be maintained > > and I as a community member decided that its probably not doable. > > > > Xyster ORM maybe existing for some time, however i haven't seen it in > > use. Additionally although they claim not be ActiveRecord you have > > to extend a certain base class for your entities to work with it. > > This is the root of all evil in ORMs and the reason why enterprise > > ORMs don't require it. > > > > The lead developer of Doctrine is indeed paid by SensioLabs, however > > the Source Code is under the LGPL, which is a perfectly compatible > > license with New BSD and doesn't restrict the use of the code. > > There is also no effort whatsoever by SensioLabs to control Doctrine. > > > > Looking at it the other way, Doctrine is already several years old, > > plus it benefits from lots of experience of the PEAR MDB2 component > > aswell as others (eZ Components, ZF). The code basis is pretty robust > > and there are people working on its perfection full time, which makes > > it a pretty good choice for Enterprises. > > > > Going for Integration with Doctrine in my opinion is one step further > > to professionaling php as an enterprise language. The different PHP > > communities where cooking their own soups for the last 10 years. Although > > I like competition very much, one should also make rational decisions > > when it is better not to reinvent the wheel. > > > > greetings, > > Benjamin > > > > On Wed, 25 Nov 2009 00:51:38 -0800 (PST), Arié Bénichou > > wrote: > >> I don't understand why you did not use http://xyster.libreworks.net/ > >> Xyster > >> ORM > >> It makes use of the Data Mapper Pattern and comes with a Unit of Work. > >> Doctrine is shifting to this approach for the version 2.0, but it's still > >> an > >> alpha release. > >> It's a pity for you to have failed this way, because, Doctrine is > >> associated > >> to SensioLabs, the french agency who developps the Symfony Framework. > > > > > > -- > View this message in context: > http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787474.html > Sent from the Zend Framework mailing list archive at Nabble.com. > -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- Arié Bénichou wrote (on Wednesday, 25 November 2009, 02:08 AM -0800): > drm-4 wrote: > > If you'd like integration for Xyster, write a proposal for it. > Please Gerard, don't tell me what i'm supposed to do. You don't get the > point here, the question is : why did'nt you use Xyster ORM? Plain and simple: there's already huge uptake of Doctrine in the ZF community, and little to no uptake of Xyster. This means there are plenty of active contributors willing and ready to do the work. > drm-4 wrote: > > And Sensio is the devil...? What's your point? Let alone the fact that > > Doctrine is simply open source (LGPL) and whatever company would be > > behind it wouldn't make any difference? Also, check your facts, because > > what you say isn't even true. > > > > SensioLabs is not the devil, obviously, it's simply your main competitor. Debatable. Yes, Sensio employs Jon Wage and others to work on Doctrine, but the reality is that Sensio does very little to determine the direction of Doctrine; Doctrine is an open source project that relies heavily, like ZF, on community contributions. Doctrine is also being used heavily in a variety of PHP frameworks, including Symfony and Agavi. Furthermore, having integration with it means that developers familiar with it can move into ZF and retain the experience they already have. This was a really important criteria in the decision. Finally, when looking at integration with other projects, you have to look at the ecosystem. Doctrine, as noted, is being widely used. Xyster ORM, on the other hand, advertises on their home page that the community consists of "1 developer." This is not a community. > It's a pity that you decided to reinvent the wheel, met a 'little > blockade', resigned and decided to go for Doctrine on this failure. It's clear you have absolutely no understanding of the rationale. Zend_Entity was being developed by a single community contributor, Ben Eberlei. He was doing a remarkable job, but, in the end, he's a single person. On the Zend side, we had neither the experience nor the resources to commit to the project -- we are two engineers and myself, none of us with experience in the theory and development of ORMs (I've certainly used them, and know the design patterns and theory behind them, but have never participated in the implementation of one). As such, unless other community members stepped up to help -- and they weren't. An additional factor was that Zend_Entity and Doctrine 2 were using the same specification -- the Java Persistence API, or JPA. As such, the implementations were basically converging. Ben and the Doctrine team were aware of this, and at a certain point, Ben had to decide whether or not it made sense to spend the time and effort on a separate implementation, or instead help the other project to completion. I don't know about you, but I actually find this inspiring. It's a rare developer who will recognize that what they're doing is repeating the work of others, and then adopt the other's code, and a highly professional position to take. Isn't it better to pool our efforts and have one high quality project than to have two similar projects of lesser quality? > You could have started by providing integration to the popular > Doctrine, then have a look to the Xyster Orm. So, as i said, it's a > pity, that you failed this way. If i were SensioLabs, > http://www.doctrine-project.org/documentation/manual/2_0/en/pdf i would rub > my hands . > > So, i will ask my question again : why did'nt you use Xyster ORM? I've answered that above. One thing I'll note though: how would adopting Xyster be any qualitatively different than adopting Doctrine? Drop the Sensio FUD -- Doctrine is an OSS project, and adopting Doctrine does not in any way affect Symfony. You haven't specified any advantages Xyster has over Doctrine. To the contrary, I've pointed to many advantages of choosing Doctrine, and several disadvantages to using Xyster. If you want to see Xyster ORM integration, you will need to create a proposal for it, just as the Doctrine working group is doing currently. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Not knowing about Xyster is called being ignorant, not misinformed ;). I'm not misinformed about Xyster - I never even knew it existed until now. The actual failure, if there was one, dates back to the beginning of ZF when an ORM was not actively pursued. Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative From: Arié Bénichou To: fw-general@lists.zend.com Sent: Wed, November 25, 2009 12:56:20 PM Subject: Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration Pádraic, It's quite easy to call someone a 'troll'. I admit the term 'failure' is probably not fair. However, that's how your competitors, from the open source world, or not, (it doesn't matter), could look at it. I sincerely did not mean to hurt or blame Benjamin who where working on his own. It's a good thing he had the maturity to 'roll-back'. It's just a pity strategically, that support for Doctrine was announced after this 'failure'. It would have been a smarter move to propose a formal Doctrine integration first, then to launch R&D on Zend_Entity. Pádraic Brady wrote: > > I also have never heard of Xyster - so it would have been a surprise to > see it adopted. > I'm the one supposed to be misinformed. -Arié Pádraic Brady wrote: > >>SensioLabs is not the devil, obviously, it's simply your main > competitor. >>It's a pity that you decided to reinvent the wheel, met a 'little blockade', >>resigned and decided to go for Doctrine on this > failure. You could have >>started by providing integration to the > popular Doctrine, then have a look >>to the Xyster Orm. So, as i said, > it's a pity, that you failed this way. If >>i were SensioLabs, >>http://www.doctrine-project.org/documentation/manual/2_0/en/pdf i would rub >>my hands. > > Either you're a troll or you're misinformed... > > You keep referring to a "failure" but leave it unspecified - Benjamin made > a decision that writing Zend_Entity et al. was simply not possible at this > time. He was the sole developer and had no assistance. > > I also have never heard of Xyster - so it would have been a surprise to > see it adopted. > > SensioLabs may be rubbing their hands for some reason, but not because our > adoption of Doctrine assists Symfony. Developers have been using Doctrine > with the Zend Framework since forever. The only thing that has changed is > making its integration a formal development goal. In my mind that is a > success given Doctrine's popularity that will actually do the opposite of > what you seem to suspect. I could say the same for other forms of > integration. > > Symfony has an advantage in that it bundles third party libraries while ZF > reinvents them or misses the features they offer (sometimes not for the > better). Maybe the integration of Doctrine will prompt a look at what else > has been missing - YAML, HTML filtering, etc. > > Paddy > > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > OpenID Europe Foundation Irish Representative > > > > > > > From: Arié Bénichou > To: fw-general@lists.zend.com > Sent: Wed, November 25, 2009 10:08:39 AM > Subject: Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine > integration > > > Hi, > > > drm-4 wrote: >> >> If you'd like integration for Xyster, write a proposal for it. >> > Please Gerard, don't tell me what i'm supposed to do. You don't get the > point here, the question is : why did'nt you use Xyster ORM? > > > drm-4 wrote: >> >> And Sensio is the devil...? What's your point? Let alone the fact that >> Doctrine is simply open source (LGPL) and whatever company would be >> behind it wouldn't make any difference? Also, check your facts, because >> what you say isn't even true. >> > > SensioLabs is not the devil, obviously, it's simply your main competitor. > It's a pity that you decided to reinvent the wheel, met a 'little > blockade', > resigned and decided to go for Doctrine on this failure. You could have > started by providing integration to the popular Doctrine, then have a look > to the Xyster Orm. So, as i said, it's a pity, that you failed this way. > If > i were SensioLabs, > http://www.doctrine-project.org/documentation/manual/2_0/en/pdf i would > rub > my hands . > > So, i will ask my question again : why did'nt you use Xyster ORM? > > -Arié > -- > View this message in context: > http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787423.html > Sent from the Zend Framework mailing list archive at Nabble.com. > > -- View this message in context: http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787521.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Pádraic, It's quite easy to call someone a 'troll'. I admit the term 'failure' is probably not fair. However, that's how your competitors, from the open source world, or not, (it doesn't matter), could look at it. I sincerely did not mean to hurt or blame Benjamin who where working on his own. It's a good thing he had the maturity to 'roll-back'. It's just a pity strategically, that support for Doctrine was announced after this 'failure'. It would have been a smarter move to propose a formal Doctrine integration first, then to launch R&D on Zend_Entity. Pádraic Brady wrote: > > I also have never heard of Xyster - so it would have been a surprise to > see it adopted. > I'm the one supposed to be misinformed. -Arié Pádraic Brady wrote: > >>SensioLabs is not the devil, obviously, it's simply your main > competitor. >>It's a pity that you decided to reinvent the wheel, met a 'little blockade', >>resigned and decided to go for Doctrine on this > failure. You could have >>started by providing integration to the > popular Doctrine, then have a look >>to the Xyster Orm. So, as i said, > it's a pity, that you failed this way. If >>i were SensioLabs, >>http://www.doctrine-project.org/documentation/manual/2_0/en/pdf i would rub >>my hands. > > Either you're a troll or you're misinformed... > > You keep referring to a "failure" but leave it unspecified - Benjamin made > a decision that writing Zend_Entity et al. was simply not possible at this > time. He was the sole developer and had no assistance. > > I also have never heard of Xyster - so it would have been a surprise to > see it adopted. > > SensioLabs may be rubbing their hands for some reason, but not because our > adoption of Doctrine assists Symfony. Developers have been using Doctrine > with the Zend Framework since forever. The only thing that has changed is > making its integration a formal development goal. In my mind that is a > success given Doctrine's popularity that will actually do the opposite of > what you seem to suspect. I could say the same for other forms of > integration. > > Symfony has an advantage in that it bundles third party libraries while ZF > reinvents them or misses the features they offer (sometimes not for the > better). Maybe the integration of Doctrine will prompt a look at what else > has been missing - YAML, HTML filtering, etc. > > Paddy > > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > OpenID Europe Foundation Irish Representative > > > > > > > From: Arié Bénichou > To: fw-general@lists.zend.com > Sent: Wed, November 25, 2009 10:08:39 AM > Subject: Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine > integration > > > Hi, > > > drm-4 wrote: >> >> If you'd like integration for Xyster, write a proposal for it. >> > Please Gerard, don't tell me what i'm supposed to do. You don't get the > point here, the question is : why did'nt you use Xyster ORM? > > > drm-4 wrote: >> >> And Sensio is the devil...? What's your point? Let alone the fact that >> Doctrine is simply open source (LGPL) and whatever company would be >> behind it wouldn't make any difference? Also, check your facts, because >> what you say isn't even true. >> > > SensioLabs is not the devil, obviously, it's simply your main competitor. > It's a pity that you decided to reinvent the wheel, met a 'little > blockade', > resigned and decided to go for Doctrine on this failure. You could have > started by providing integration to the popular Doctrine, then have a look > to the Xyster Orm. So, as i said, it's a pity, that you failed this way. > If > i were SensioLabs, > http://www.doctrine-project.org/documentation/manual/2_0/en/pdf i would > rub > my hands . > > So, i will ask my question again : why did'nt you use Xyster ORM? > > -Arié > -- > View this message in context: > http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787423.html > Sent from the Zend Framework mailing list archive at Nabble.com. > > -- View this message in context: http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787521.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi Gerard, You completely misunderstood my post. This post is not about how I'm looking at open source. It's quite simple : why did'nt you use Xyster ORM? Benjamin gave me a partial answer with the base class entity problem. -Arié drm-4 wrote: > > Hi, > > Arié Bénichou wrote: >> Please Gerard, don't tell me what i'm supposed to do. You don't get the >> point here, the question is : why did'nt you use Xyster ORM? >> > Indeed I don't get the point. And I think that is because your reasoning > is flawed. You are basically saying we should use Xyster, because we > should not use Doctrine. Imho you should keep these two issues separate. > First: why not use Doctrine. Second: why use Xyster. > > Regarding the first, I disagree with your point that Sensiolabs is "the > competitor". If sensiolabs decides to be heavily involved in the > development of Doctrine, all the better for us (as in: users of open > source), because it is good for the continuation of the project. If > you're in any way hostile towards sensiolabs, just because they thought > of symfony, you're (imho) looking at open source the wrong way. The only > thing that really counts is licensing, because that gives us (again: > users of open source) freedom. > > Regarding the second: I'm sorry I gave you the idea that I'm telling you > what to do. Let me rephrase: you are cordially invited to write a > proposal. > > > Gerard > > -- View this message in context: http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787481.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
>SensioLabs is not the devil, obviously, it's simply your main competitor. >It's a pity that you decided to reinvent the wheel, met a 'little blockade', >resigned and decided to go for Doctrine on this failure. You could have >started by providing integration to the popular Doctrine, then have a look >to the Xyster Orm. So, as i said, it's a pity, that you failed this way. If >i were SensioLabs, >http://www.doctrine-project.org/documentation/manual/2_0/en/pdf i would rub >my hands. Either you're a troll or you're misinformed... You keep referring to a "failure" but leave it unspecified - Benjamin made a decision that writing Zend_Entity et al. was simply not possible at this time. He was the sole developer and had no assistance. I also have never heard of Xyster - so it would have been a surprise to see it adopted. SensioLabs may be rubbing their hands for some reason, but not because our adoption of Doctrine assists Symfony. Developers have been using Doctrine with the Zend Framework since forever. The only thing that has changed is making its integration a formal development goal. In my mind that is a success given Doctrine's popularity that will actually do the opposite of what you seem to suspect. I could say the same for other forms of integration. Symfony has an advantage in that it bundles third party libraries while ZF reinvents them or misses the features they offer (sometimes not for the better). Maybe the integration of Doctrine will prompt a look at what else has been missing - YAML, HTML filtering, etc. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative From: Arié Bénichou To: fw-general@lists.zend.com Sent: Wed, November 25, 2009 10:08:39 AM Subject: Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration Hi, drm-4 wrote: > > If you'd like integration for Xyster, write a proposal for it. > Please Gerard, don't tell me what i'm supposed to do. You don't get the point here, the question is : why did'nt you use Xyster ORM? drm-4 wrote: > > And Sensio is the devil...? What's your point? Let alone the fact that > Doctrine is simply open source (LGPL) and whatever company would be > behind it wouldn't make any difference? Also, check your facts, because > what you say isn't even true. > SensioLabs is not the devil, obviously, it's simply your main competitor. It's a pity that you decided to reinvent the wheel, met a 'little blockade', resigned and decided to go for Doctrine on this failure. You could have started by providing integration to the popular Doctrine, then have a look to the Xyster Orm. So, as i said, it's a pity, that you failed this way. If i were SensioLabs, http://www.doctrine-project.org/documentation/manual/2_0/en/pdf i would rub my hands . So, i will ask my question again : why did'nt you use Xyster ORM? -Arié -- View this message in context: http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787423.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi Benjamin, Thanks for your reply. Reading the http://www.doctrine-project.org/blog/php-5-3-and-doctrine-2-0-teaser doctrine 2.0 teaser , I noticed that Doctrine planned to eliminate the need for an entity to extend from a base class. Althought, it sounds like writing an entity class is a little bit easier, since it can be any plain old php object, the reasons were not given. Then you said, a such base class is the root of all evils... Could you please, explain the difficulties you faced with entities having to extend a base class? greetings, -Arié beberlei wrote: > > > Hello, > > Its not a failure to recognize that a proposal generates lots of > "duplicate > code", which is currently better solved in other projects. This also > has nothing to do with Zend, since the component was approved > under the premise that its community contributed. An ORM is a huge > undertaking and it creates lots of code that has to be maintained > and I as a community member decided that its probably not doable. > > Xyster ORM maybe existing for some time, however i haven't seen it in > use. Additionally although they claim not be ActiveRecord you have > to extend a certain base class for your entities to work with it. > This is the root of all evil in ORMs and the reason why enterprise > ORMs don't require it. > > The lead developer of Doctrine is indeed paid by SensioLabs, however > the Source Code is under the LGPL, which is a perfectly compatible > license with New BSD and doesn't restrict the use of the code. > There is also no effort whatsoever by SensioLabs to control Doctrine. > > Looking at it the other way, Doctrine is already several years old, > plus it benefits from lots of experience of the PEAR MDB2 component > aswell as others (eZ Components, ZF). The code basis is pretty robust > and there are people working on its perfection full time, which makes > it a pretty good choice for Enterprises. > > Going for Integration with Doctrine in my opinion is one step further > to professionaling php as an enterprise language. The different PHP > communities where cooking their own soups for the last 10 years. Although > I like competition very much, one should also make rational decisions > when it is better not to reinvent the wheel. > > greetings, > Benjamin > > On Wed, 25 Nov 2009 00:51:38 -0800 (PST), Arié Bénichou > wrote: >> I don't understand why you did not use http://xyster.libreworks.net/ >> Xyster >> ORM >> It makes use of the Data Mapper Pattern and comes with a Unit of Work. >> Doctrine is shifting to this approach for the version 2.0, but it's still >> an >> alpha release. >> It's a pity for you to have failed this way, because, Doctrine is >> associated >> to SensioLabs, the french agency who developps the Symfony Framework. > > -- View this message in context: http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787474.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi, Arié Bénichou wrote: Please Gerard, don't tell me what i'm supposed to do. You don't get the point here, the question is : why did'nt you use Xyster ORM? Indeed I don't get the point. And I think that is because your reasoning is flawed. You are basically saying we should use Xyster, because we should not use Doctrine. Imho you should keep these two issues separate. First: why not use Doctrine. Second: why use Xyster. Regarding the first, I disagree with your point that Sensiolabs is "the competitor". If sensiolabs decides to be heavily involved in the development of Doctrine, all the better for us (as in: users of open source), because it is good for the continuation of the project. If you're in any way hostile towards sensiolabs, just because they thought of symfony, you're (imho) looking at open source the wrong way. The only thing that really counts is licensing, because that gives us (again: users of open source) freedom. Regarding the second: I'm sorry I gave you the idea that I'm telling you what to do. Let me rephrase: you are cordially invited to write a proposal. Gerard
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi, drm-4 wrote: > > If you'd like integration for Xyster, write a proposal for it. > Please Gerard, don't tell me what i'm supposed to do. You don't get the point here, the question is : why did'nt you use Xyster ORM? drm-4 wrote: > > And Sensio is the devil...? What's your point? Let alone the fact that > Doctrine is simply open source (LGPL) and whatever company would be > behind it wouldn't make any difference? Also, check your facts, because > what you say isn't even true. > SensioLabs is not the devil, obviously, it's simply your main competitor. It's a pity that you decided to reinvent the wheel, met a 'little blockade', resigned and decided to go for Doctrine on this failure. You could have started by providing integration to the popular Doctrine, then have a look to the Xyster Orm. So, as i said, it's a pity, that you failed this way. If i were SensioLabs, http://www.doctrine-project.org/documentation/manual/2_0/en/pdf i would rub my hands . So, i will ask my question again : why did'nt you use Xyster ORM? -Arié -- View this message in context: http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787423.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hello, Its not a failure to recognize that a proposal generates lots of "duplicate code", which is currently better solved in other projects. This also has nothing to do with Zend, since the component was approved under the premise that its community contributed. An ORM is a huge undertaking and it creates lots of code that has to be maintained and I as a community member decided that its probably not doable. Xyster ORM maybe existing for some time, however i haven't seen it in use. Additionally although they claim not be ActiveRecord you have to extend a certain base class for your entities to work with it. This is the root of all evil in ORMs and the reason why enterprise ORMs don't require it. The lead developer of Doctrine is indeed paid by SensioLabs, however the Source Code is under the LGPL, which is a perfectly compatible license with New BSD and doesn't restrict the use of the code. There is also no effort whatsoever by SensioLabs to control Doctrine. Looking at it the other way, Doctrine is already several years old, plus it benefits from lots of experience of the PEAR MDB2 component aswell as others (eZ Components, ZF). The code basis is pretty robust and there are people working on its perfection full time, which makes it a pretty good choice for Enterprises. Going for Integration with Doctrine in my opinion is one step further to professionaling php as an enterprise language. The different PHP communities where cooking their own soups for the last 10 years. Although I like competition very much, one should also make rational decisions when it is better not to reinvent the wheel. greetings, Benjamin On Wed, 25 Nov 2009 00:51:38 -0800 (PST), Arié Bénichou wrote: > I don't understand why you did not use http://xyster.libreworks.net/ > Xyster > ORM > It makes use of the Data Mapper Pattern and comes with a Unit of Work. > Doctrine is shifting to this approach for the version 2.0, but it's still > an > alpha release. > It's a pity for you to have failed this way, because, Doctrine is > associated > to SensioLabs, the french agency who developps the Symfony Framework.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi Arié Arié Bénichou wrote: I don't understand why you did not use http://xyster.libreworks.net/ Xyster ORM It makes use of the Data Mapper Pattern and comes with a Unit of Work. Doctrine is shifting to this approach for the version 2.0, but it's still an alpha release. If you'd like integration for Xyster, write a proposal for it. It's a pity for you to have failed this way, because, Doctrine is associated to SensioLabs, the french agency who developps the Symfony Framework. And Sensio is the devil...? What's your point? Let alone the fact that Doctrine is simply open source (LGPL) and whatever company would be behind it wouldn't make any difference? Also, check your facts, because what you say isn't even true. drm / Gerard
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I don't understand why you did not use http://xyster.libreworks.net/ Xyster ORM It makes use of the Data Mapper Pattern and comes with a Unit of Work. Doctrine is shifting to this approach for the version 2.0, but it's still an alpha release. It's a pity for you to have failed this way, because, Doctrine is associated to SensioLabs, the french agency who developps the Symfony Framework. -- View this message in context: http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787382.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Would be ZendX_Doctrine_AuthAdapter (or something), wouldn't it? -Matt On Wed, Nov 4, 2009 at 1:10 PM, A.J. Brown wrote: > Can we make sure the ZendX_Auth_Adapter_Doctrine gets into the > standard library whenever the integration happens? > > > http://framework.zend.com/svn/framework/extras/incubator/library/ZendX/Doctrine/Auth/Adapter.php > > > On Tue, Nov 3, 2009 at 1:44 PM, Giorgio Sironi > wrote: > > For the Dependency Injection debate, until now I managed to work with > > factories only. It is manual dependency injection but it works. > > > > However, Doctrine integration would be very useful since many developers > are > > going to manually integrate it anyway. Maybe there is the possibility to > > ship with it, just like with dojo? > > Zend_Entity and Doctrine2 were actually very similar and I think their > Api > > is more or less the same. But Doctrine2 is nearly completed and widely > > tested, and it is already namespaced and performant. > > > > > > -- > > Giorgio Sironi > > Piccolo Principe & Web Engineer > > http://giorgiosironi.blogspot.com > > http://twitter.com/giorgiosironi > > > > > > -- > A.J. Brown > web | http://ajbrown.org > phone | (937) 660-3969 >
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Can we make sure the ZendX_Auth_Adapter_Doctrine gets into the standard library whenever the integration happens? http://framework.zend.com/svn/framework/extras/incubator/library/ZendX/Doctrine/Auth/Adapter.php On Tue, Nov 3, 2009 at 1:44 PM, Giorgio Sironi wrote: > For the Dependency Injection debate, until now I managed to work with > factories only. It is manual dependency injection but it works. > > However, Doctrine integration would be very useful since many developers are > going to manually integrate it anyway. Maybe there is the possibility to > ship with it, just like with dojo? > Zend_Entity and Doctrine2 were actually very similar and I think their Api > is more or less the same. But Doctrine2 is nearly completed and widely > tested, and it is already namespaced and performant. > > > -- > Giorgio Sironi > Piccolo Principe & Web Engineer > http://giorgiosironi.blogspot.com > http://twitter.com/giorgiosironi > -- A.J. Brown web | http://ajbrown.org phone | (937) 660-3969
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
For the Dependency Injection debate, until now I managed to work with factories only. It is manual dependency injection but it works. However, Doctrine integration would be very useful since many developers are going to manually integrate it anyway. Maybe there is the possibility to ship with it, just like with dojo? Zend_Entity and Doctrine2 were actually very similar and I think their Api is more or less the same. But Doctrine2 is nearly completed and widely tested, and it is already namespaced and performant. -- Giorgio Sironi Piccolo Principe & Web Engineer http://giorgiosironi.blogspot.com http://twitter.com/giorgiosironi
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/31 Pádraic Brady : > I think Matthew is pointing out that there have always been doubts about > utilising a DI container in light weight languages like PHP, Python, and > Ruby. In essence, it's remarkably hard to create a valid use case for a DI > container. You can create any number of artificial examples, but the light > weightedness of PHP, it's tolerance for loose coupling, and the minimal code > it generates (all reasons why we use it) make using DI overkill - probably > in 95% or more of the common uses for PHP. > > There are some interesting case studies in Ruby if you go looking where > individuals have experiemented in writing a DI container/framework for Ruby. > Ruby has several Di containers/frameworks - nearly all them are classified > as dormant. Ruby has one very neat thing over PHP - you can overload object > instantiation. > > This is not to say a DI container is useless or meaningless, but the > classical concept of a DI container from Java or C# is only marginally > useful in PHP. In most respects all you really need is a little substitution > and light mapping. If that's the goal of any future DI work in ZF, then > please, fire on all cylinders. Whether that would qualify as a DI container > or not is anyone's guess ;). Once you start accumulating more features, more > complex mapping, and more classical injection methods - then it will bury > itself into oblivion as an overarchitected mess 99% of PHP developers just > do not need. Thanks for the informative debate, I suppose it breaks down to how much you use something like a DI Container in an application, like most things in life :) Most of the testability problems can be overcome by using manual injection / lazy injection and things like the universal construct anyway Sorry to keep this thread going for so long I went a bit off topic :) > > My 2c :) > > Paddy > > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > OpenID Europe Foundation Irish Representative > > > ________________ > From: keith Pope > To: fw-general@lists.zend.com > Sent: Fri, October 30, 2009 7:19:25 PM > Subject: Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine > integration > > 2009/10/30 Matthew Weier O'Phinney : >> -- keith Pope wrote >> (on Friday, 30 October 2009, 04:43 PM +): >>> 2009/10/30 Matthew Weier O'Phinney : >>> > -- keith Pope wrote >>> > (on Friday, 30 October 2009, 04:02 PM +): >>> > > 2009/10/30 Ralph Schindler : >>> > > Also will we be deprecating Zend_Db as if we have tight Doctrine >>> > > integration is there any reason to keep Zend_Db? >>> > >>> > There are plenty of reasons to keep Zend_Db. Not everyone will be using >>> > Doctrine, and for many one-off types of applications (single tables, or >>> > multiple tables with no relations, etc.), having Zend_Db around will >>> > continue to be essential. Additionally, one aspect I'd like to explore >>> > with the Doctrine folks is potentially allowing Zend_Db adapters as >>> > Doctrine RDBMS adapters; this would provide some very interesting >>> > integration points. >>> >>> Sounds interesting I look forward to seeing this initiative develop >>> further, I would be happy to help in any way I can :) >>> >>> Once we have the integration especially with doctrine 2 would there be >>> any further plans to look at things like dependency injection, >>> criteria objects and repositories or any other DDD tools? To me having >>> a full suite of tools like this would be a great long term goal? >> >> DI is something we're already planning for -- you'll note the "unified >> constructor" pattern in all new components. Whether or not we'll have a >> DI _container_ is another question; I'm not entirely convinced DI >> containers have a good place in stateless applications, but I'll let >> Ralph talk more to that point. :) > > That is an interesting point, I dont quite understand how state > affects object dependencies or is the container an unnecessary > overhead when you are working in a limited state environment? > Something I may have to ponder > >> >> As for criteria objects, we've just approved another of Ben's >> components, some extensions to Zend_Db_Expr. One aspect I particularly >> like with it is that, combined with Zend_Db_Select, we are getting to a >> point where we have an almost complete criteria object for select >> operations. This could certainly be adapted for use with DDD fairly >> easily. Regarding repositories, Zend_Application_Bootstrap actually >> already acts as one in many ways -- though we may do more with this >> and/or service locators for 2.0. >> >> -- >> Matthew Weier O'Phinney >> Project Lead | matt...@zend.com >> Zend Framework | http://framework.zend.com/ >> > > > > -- > > http://www.thepopeisdead.com > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I think Matthew is pointing out that there have always been doubts about utilising a DI container in light weight languages like PHP, Python, and Ruby. In essence, it's remarkably hard to create a valid use case for a DI container. You can create any number of artificial examples, but the light weightedness of PHP, it's tolerance for loose coupling, and the minimal code it generates (all reasons why we use it) make using DI overkill - probably in 95% or more of the common uses for PHP. There are some interesting case studies in Ruby if you go looking where individuals have experiemented in writing a DI container/framework for Ruby. Ruby has several Di containers/frameworks - nearly all them are classified as dormant. Ruby has one very neat thing over PHP - you can overload object instantiation. This is not to say a DI container is useless or meaningless, but the classical concept of a DI container from Java or C# is only marginally useful in PHP. In most respects all you really need is a little substitution and light mapping. If that's the goal of any future DI work in ZF, then please, fire on all cylinders. Whether that would qualify as a DI container or not is anyone's guess ;). Once you start accumulating more features, more complex mapping, and more classical injection methods - then it will bury itself into oblivion as an overarchitected mess 99% of PHP developers just do not need. My 2c :) Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative From: keith Pope To: fw-general@lists.zend.com Sent: Fri, October 30, 2009 7:19:25 PM Subject: Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration 2009/10/30 Matthew Weier O'Phinney : > -- keith Pope wrote > (on Friday, 30 October 2009, 04:43 PM +): >> 2009/10/30 Matthew Weier O'Phinney : >> > -- keith Pope wrote >> > (on Friday, 30 October 2009, 04:02 PM +): >> > > 2009/10/30 Ralph Schindler : >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine >> > > integration is there any reason to keep Zend_Db? >> > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using >> > Doctrine, and for many one-off types of applications (single tables, or >> > multiple tables with no relations, etc.), having Zend_Db around will >> > continue to be essential. Additionally, one aspect I'd like to explore >> > with the Doctrine folks is potentially allowing Zend_Db adapters as >> > Doctrine RDBMS adapters; this would provide some very interesting >> > integration points. >> >> Sounds interesting I look forward to seeing this initiative develop >> further, I would be happy to help in any way I can :) >> >> Once we have the integration especially with doctrine 2 would there be >> any further plans to look at things like dependency injection, >> criteria objects and repositories or any other DDD tools? To me having >> a full suite of tools like this would be a great long term goal? > > DI is something we're already planning for -- you'll note the "unified > constructor" pattern in all new components. Whether or not we'll have a > DI _container_ is another question; I'm not entirely convinced DI > containers have a good place in stateless applications, but I'll let > Ralph talk more to that point. :) That is an interesting point, I dont quite understand how state affects object dependencies or is the container an unnecessary overhead when you are working in a limited state environment? Something I may have to ponder > > As for criteria objects, we've just approved another of Ben's > components, some extensions to Zend_Db_Expr. One aspect I particularly > like with it is that, combined with Zend_Db_Select, we are getting to a > point where we have an almost complete criteria object for select > operations. This could certainly be adapted for use with DDD fairly > easily. Regarding repositories, Zend_Application_Bootstrap actually > already acts as one in many ways -- though we may do more with this > and/or service locators for 2.0. > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- keith Pope wrote (on Friday, 30 October 2009, 07:19 PM +): > 2009/10/30 Matthew Weier O'Phinney : > > -- keith Pope wrote > > (on Friday, 30 October 2009, 04:43 PM +): > >> 2009/10/30 Matthew Weier O'Phinney : > >> > -- keith Pope wrote > >> > (on Friday, 30 October 2009, 04:02 PM +): > >> > > 2009/10/30 Ralph Schindler : > >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine > >> > > integration is there any reason to keep Zend_Db? > >> > > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using > >> > Doctrine, and for many one-off types of applications (single tables, or > >> > multiple tables with no relations, etc.), having Zend_Db around will > >> > continue to be essential. Additionally, one aspect I'd like to explore > >> > with the Doctrine folks is potentially allowing Zend_Db adapters as > >> > Doctrine RDBMS adapters; this would provide some very interesting > >> > integration points. > >> > >> Sounds interesting I look forward to seeing this initiative develop > >> further, I would be happy to help in any way I can :) > >> > >> Once we have the integration especially with doctrine 2 would there be > >> any further plans to look at things like dependency injection, > >> criteria objects and repositories or any other DDD tools? To me having > >> a full suite of tools like this would be a great long term goal? > > > > DI is something we're already planning for -- you'll note the "unified > > constructor" pattern in all new components. Whether or not we'll have a > > DI _container_ is another question; I'm not entirely convinced DI > > containers have a good place in stateless applications, but I'll let > > Ralph talk more to that point. :) > > That is an interesting point, I dont quite understand how state > affects object dependencies or is the container an unnecessary > overhead when you are working in a limited state environment? > Something I may have to ponder There are two things: * Depending on the architecture of the DI container, you may end up with many objects instantiated which are never used -- leading to overhead. DI containers evolved in large part in Java, where you want to preload everything, as eventually everything will be loaded anyways. This is not true of PHP applications, where often what is loaded is determined by the execution path. * Complexity of setup. When you have a DI container, you often have large, complicated dependency setups that are difficult to understand unless you understand the entire application architecture. This can make learning the framework and/or individual applications much more difficult -- as well as determining where and when in the configuration to make changes. For examples, look at tomcat or any atlassian tool (not to dis the tools, but they all exhibit very complex dependency setups). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi, Also, this is my resource which i use: http://pastebin.com/d207ac465 Just add to config: resources.database.connection_string = "mysql://user:p...@localhost/db" resources.database.compiled = false; use compiled version of Doctrine It enables autoloading for models and tables, utf-8 for connection, validation on save and dql callbacks. P.S. It expects Doctrine to be in library/Doctrine/Doctrine.php. It is like that because i use svn:externals to update doctrine and don't want to have it straight in my library folder -- Juozas Kaziukėnas (juo...@juokaz.com) Aš internete - JuoKaz (http://www.juokaz.com) On Fri, Oct 30, 2009 at 7:30 PM, A.J. Brown wrote: > For those that are interested in my resource class: > > http://gist.github.com/222645 > > I'm also working on making a resource for the CLI components, so that > you can do deployments from within your Zend Framework application. > For example, if the environment is a testing server, the application > will automatically do a build-all-reload. Or perhaps the application > will automatically run migrations when new ones are detected. > > This is just a starting point. > > On Fri, Oct 30, 2009 at 1:23 PM, Matthew Weier O'Phinney > wrote: > > -- keith Pope wrote > > (on Friday, 30 October 2009, 04:43 PM +): > >> 2009/10/30 Matthew Weier O'Phinney : > >> > -- keith Pope wrote > >> > (on Friday, 30 October 2009, 04:02 PM +): > >> > > 2009/10/30 Ralph Schindler : > >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine > >> > > integration is there any reason to keep Zend_Db? > >> > > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be > using > >> > Doctrine, and for many one-off types of applications (single tables, > or > >> > multiple tables with no relations, etc.), having Zend_Db around will > >> > continue to be essential. Additionally, one aspect I'd like to explore > >> > with the Doctrine folks is potentially allowing Zend_Db adapters as > >> > Doctrine RDBMS adapters; this would provide some very interesting > >> > integration points. > >> > >> Sounds interesting I look forward to seeing this initiative develop > >> further, I would be happy to help in any way I can :) > >> > >> Once we have the integration especially with doctrine 2 would there be > >> any further plans to look at things like dependency injection, > >> criteria objects and repositories or any other DDD tools? To me having > >> a full suite of tools like this would be a great long term goal? > > > > DI is something we're already planning for -- you'll note the "unified > > constructor" pattern in all new components. Whether or not we'll have a > > DI _container_ is another question; I'm not entirely convinced DI > > containers have a good place in stateless applications, but I'll let > > Ralph talk more to that point. :) > > > > As for criteria objects, we've just approved another of Ben's > > components, some extensions to Zend_Db_Expr. One aspect I particularly > > like with it is that, combined with Zend_Db_Select, we are getting to a > > point where we have an almost complete criteria object for select > > operations. This could certainly be adapted for use with DDD fairly > > easily. Regarding repositories, Zend_Application_Bootstrap actually > > already acts as one in many ways -- though we may do more with this > > and/or service locators for 2.0. > > > > -- > > Matthew Weier O'Phinney > > Project Lead| matt...@zend.com > > Zend Framework | http://framework.zend.com/ > > > > > > -- > A.J. Brown > web | http://ajbrown.org > phone | (937) 660-3969 >
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
For those that are interested in my resource class: http://gist.github.com/222645 I'm also working on making a resource for the CLI components, so that you can do deployments from within your Zend Framework application. For example, if the environment is a testing server, the application will automatically do a build-all-reload. Or perhaps the application will automatically run migrations when new ones are detected. This is just a starting point. On Fri, Oct 30, 2009 at 1:23 PM, Matthew Weier O'Phinney wrote: > -- keith Pope wrote > (on Friday, 30 October 2009, 04:43 PM +): >> 2009/10/30 Matthew Weier O'Phinney : >> > -- keith Pope wrote >> > (on Friday, 30 October 2009, 04:02 PM +): >> > > 2009/10/30 Ralph Schindler : >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine >> > > integration is there any reason to keep Zend_Db? >> > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using >> > Doctrine, and for many one-off types of applications (single tables, or >> > multiple tables with no relations, etc.), having Zend_Db around will >> > continue to be essential. Additionally, one aspect I'd like to explore >> > with the Doctrine folks is potentially allowing Zend_Db adapters as >> > Doctrine RDBMS adapters; this would provide some very interesting >> > integration points. >> >> Sounds interesting I look forward to seeing this initiative develop >> further, I would be happy to help in any way I can :) >> >> Once we have the integration especially with doctrine 2 would there be >> any further plans to look at things like dependency injection, >> criteria objects and repositories or any other DDD tools? To me having >> a full suite of tools like this would be a great long term goal? > > DI is something we're already planning for -- you'll note the "unified > constructor" pattern in all new components. Whether or not we'll have a > DI _container_ is another question; I'm not entirely convinced DI > containers have a good place in stateless applications, but I'll let > Ralph talk more to that point. :) > > As for criteria objects, we've just approved another of Ben's > components, some extensions to Zend_Db_Expr. One aspect I particularly > like with it is that, combined with Zend_Db_Select, we are getting to a > point where we have an almost complete criteria object for select > operations. This could certainly be adapted for use with DDD fairly > easily. Regarding repositories, Zend_Application_Bootstrap actually > already acts as one in many ways -- though we may do more with this > and/or service locators for 2.0. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- A.J. Brown web | http://ajbrown.org phone | (937) 660-3969
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/30 Matthew Weier O'Phinney : > -- keith Pope wrote > (on Friday, 30 October 2009, 04:43 PM +): >> 2009/10/30 Matthew Weier O'Phinney : >> > -- keith Pope wrote >> > (on Friday, 30 October 2009, 04:02 PM +): >> > > 2009/10/30 Ralph Schindler : >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine >> > > integration is there any reason to keep Zend_Db? >> > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using >> > Doctrine, and for many one-off types of applications (single tables, or >> > multiple tables with no relations, etc.), having Zend_Db around will >> > continue to be essential. Additionally, one aspect I'd like to explore >> > with the Doctrine folks is potentially allowing Zend_Db adapters as >> > Doctrine RDBMS adapters; this would provide some very interesting >> > integration points. >> >> Sounds interesting I look forward to seeing this initiative develop >> further, I would be happy to help in any way I can :) >> >> Once we have the integration especially with doctrine 2 would there be >> any further plans to look at things like dependency injection, >> criteria objects and repositories or any other DDD tools? To me having >> a full suite of tools like this would be a great long term goal? > > DI is something we're already planning for -- you'll note the "unified > constructor" pattern in all new components. Whether or not we'll have a > DI _container_ is another question; I'm not entirely convinced DI > containers have a good place in stateless applications, but I'll let > Ralph talk more to that point. :) That is an interesting point, I dont quite understand how state affects object dependencies or is the container an unnecessary overhead when you are working in a limited state environment? Something I may have to ponder > > As for criteria objects, we've just approved another of Ben's > components, some extensions to Zend_Db_Expr. One aspect I particularly > like with it is that, combined with Zend_Db_Select, we are getting to a > point where we have an almost complete criteria object for select > operations. This could certainly be adapted for use with DDD fairly > easily. Regarding repositories, Zend_Application_Bootstrap actually > already acts as one in many ways -- though we may do more with this > and/or service locators for 2.0. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- keith Pope wrote (on Friday, 30 October 2009, 04:43 PM +): > 2009/10/30 Matthew Weier O'Phinney : > > -- keith Pope wrote > > (on Friday, 30 October 2009, 04:02 PM +): > > > 2009/10/30 Ralph Schindler : > > > Also will we be deprecating Zend_Db as if we have tight Doctrine > > > integration is there any reason to keep Zend_Db? > > > > There are plenty of reasons to keep Zend_Db. Not everyone will be using > > Doctrine, and for many one-off types of applications (single tables, or > > multiple tables with no relations, etc.), having Zend_Db around will > > continue to be essential. Additionally, one aspect I'd like to explore > > with the Doctrine folks is potentially allowing Zend_Db adapters as > > Doctrine RDBMS adapters; this would provide some very interesting > > integration points. > > Sounds interesting I look forward to seeing this initiative develop > further, I would be happy to help in any way I can :) > > Once we have the integration especially with doctrine 2 would there be > any further plans to look at things like dependency injection, > criteria objects and repositories or any other DDD tools? To me having > a full suite of tools like this would be a great long term goal? DI is something we're already planning for -- you'll note the "unified constructor" pattern in all new components. Whether or not we'll have a DI _container_ is another question; I'm not entirely convinced DI containers have a good place in stateless applications, but I'll let Ralph talk more to that point. :) As for criteria objects, we've just approved another of Ben's components, some extensions to Zend_Db_Expr. One aspect I particularly like with it is that, combined with Zend_Db_Select, we are getting to a point where we have an almost complete criteria object for select operations. This could certainly be adapted for use with DDD fairly easily. Regarding repositories, Zend_Application_Bootstrap actually already acts as one in many ways -- though we may do more with this and/or service locators for 2.0. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/30 Matthew Weier O'Phinney : > -- keith Pope wrote > (on Friday, 30 October 2009, 04:02 PM +): >> 2009/10/30 Ralph Schindler : >> > > Time to go back to using Doctrine then :( bye bye nice models. >> > > >> > > Do you think it would be a good idea to update the Quickstart guide >> > > now to not use the Data Mapper pattern and use doctrine instead? >> > >> > I would strongly disagree with that move. I think ZF has always offered 2 >> > solid solutions to modeling: use our Data classes (Table Row, etc) to build >> > out a proper model, OR use a 3rd Party ORM framework- like Doctrine. >> > >> > At ZendCon, i've heard more than one person say "This is the way modeling >> > should be done" after seeing matthew's talk on >> > >> > http://www.slideshare.net/weierophinney/architecting-your-models >> > >> > If a project doesn't have the resources to model their data like that, or >> > they need to leverage the Doctrine ecosystem to get a project done in time. >> > But in the most ideal world (where resources are not an issue), I too >> > think that this presentation shows how things should be done. >> > >> > That said, I think the quickstart should show both options, but focus on >> > the >> > Data Mapper, Service Layer stuff. >> >> I agree that the data mapper is a good way to do Models etc but I >> think the basic mapper shown in the quickstart does lead people into >> trouble. If a newcomer follows the quickstart they soon find out that >> modeling relations is very hard and they need an ORM...If we had >> Doctrine 2 integration we can then show the data mapper pattern at its >> best IMO. >> >> I have had this concern with the quickstart for a while :) > > I think we can show the current data mapper still, but then have a note > detailing ORMs and when you need to start using one (vs. a simple > hand-written data mapper). Yeah I think thats all thats needed, the only reason I raised it was that I have been asked a couple of times about the quickstart :) > >> Also will we be deprecating Zend_Db as if we have tight Doctrine >> integration is there any reason to keep Zend_Db? > > There are plenty of reasons to keep Zend_Db. Not everyone will be using > Doctrine, and for many one-off types of applications (single tables, or > multiple tables with no relations, etc.), having Zend_Db around will > continue to be essential. Additionally, one aspect I'd like to explore > with the Doctrine folks is potentially allowing Zend_Db adapters as > Doctrine RDBMS adapters; this would provide some very interesting > integration points. Sounds interesting I look forward to seeing this initiative develop further, I would be happy to help in any way I can :) Once we have the integration especially with doctrine 2 would there be any further plans to look at things like dependency injection, criteria objects and repositories or any other DDD tools? To me having a full suite of tools like this would be a great long term goal? > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- keith Pope wrote (on Friday, 30 October 2009, 04:02 PM +): > 2009/10/30 Ralph Schindler : > > > Time to go back to using Doctrine then :( bye bye nice models. > > > > > > Do you think it would be a good idea to update the Quickstart guide > > > now to not use the Data Mapper pattern and use doctrine instead? > > > > I would strongly disagree with that move. I think ZF has always offered 2 > > solid solutions to modeling: use our Data classes (Table Row, etc) to build > > out a proper model, OR use a 3rd Party ORM framework- like Doctrine. > > > > At ZendCon, i've heard more than one person say "This is the way modeling > > should be done" after seeing matthew's talk on > > > > http://www.slideshare.net/weierophinney/architecting-your-models > > > > If a project doesn't have the resources to model their data like that, or > > they need to leverage the Doctrine ecosystem to get a project done in time. > > But in the most ideal world (where resources are not an issue), I too > > think that this presentation shows how things should be done. > > > > That said, I think the quickstart should show both options, but focus on the > > Data Mapper, Service Layer stuff. > > I agree that the data mapper is a good way to do Models etc but I > think the basic mapper shown in the quickstart does lead people into > trouble. If a newcomer follows the quickstart they soon find out that > modeling relations is very hard and they need an ORM...If we had > Doctrine 2 integration we can then show the data mapper pattern at its > best IMO. > > I have had this concern with the quickstart for a while :) I think we can show the current data mapper still, but then have a note detailing ORMs and when you need to start using one (vs. a simple hand-written data mapper). > Also will we be deprecating Zend_Db as if we have tight Doctrine > integration is there any reason to keep Zend_Db? There are plenty of reasons to keep Zend_Db. Not everyone will be using Doctrine, and for many one-off types of applications (single tables, or multiple tables with no relations, etc.), having Zend_Db around will continue to be essential. Additionally, one aspect I'd like to explore with the Doctrine folks is potentially allowing Zend_Db adapters as Doctrine RDBMS adapters; this would provide some very interesting integration points. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi Keith, I agree that the data mapper is a good way to do Models etc but I think the basic mapper shown in the quickstart does lead people into trouble. If a newcomer follows the quickstart they soon find out that modeling relations is very hard and they need an ORM...If we had Doctrine 2 integration we can then show the data mapper pattern at its best IMO. I have had this concern with the quickstart for a while :) You might be on a slippery slope here. I don't think Zend Framework should dictate how people design their applications. Sure you can encourage the use of good patterns, etc, but the choice is ultimately the user's, and if the user is not capable of making those decisions based on what they know, they might not be the right person for the right job, to be frank... I think one of ZF's unique selling points is that you can use a fraction of the framework or stack all kinds of parts on each other, but (almost) never being forced to use large code bases that you don't really need. Good design doesn't dictate implementation, imo. Also will we be deprecating Zend_Db as if we have tight Doctrine integration is there any reason to keep Zend_Db? Please keep Zend_Db! I've never used it, but making Zend Framework so much dependent on another framework is never a good thing.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/30 Ralph Schindler : > >> >> Time to go back to using Doctrine then :( bye bye nice models. >> >> Do you think it would be a good idea to update the Quickstart guide >> now to not use the Data Mapper pattern and use doctrine instead? >> > > I would strongly disagree with that move. I think ZF has always offered 2 > solid solutions to modeling: use our Data classes (Table Row, etc) to build > out a proper model, OR use a 3rd Party ORM framework- like Doctrine. > > At ZendCon, i've heard more than one person say "This is the way modeling > should be done" after seeing matthew's talk on > > http://www.slideshare.net/weierophinney/architecting-your-models > > If a project doesn't have the resources to model their data like that, or > they need to leverage the Doctrine ecosystem to get a project done in time. > But in the most ideal world (where resources are not an issue), I too > think that this presentation shows how things should be done. > > That said, I think the quickstart should show both options, but focus on the > Data Mapper, Service Layer stuff. I agree that the data mapper is a good way to do Models etc but I think the basic mapper shown in the quickstart does lead people into trouble. If a newcomer follows the quickstart they soon find out that modeling relations is very hard and they need an ORM...If we had Doctrine 2 integration we can then show the data mapper pattern at its best IMO. I have had this concern with the quickstart for a while :) Also will we be deprecating Zend_Db as if we have tight Doctrine integration is there any reason to keep Zend_Db? > > -ralph > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Time to go back to using Doctrine then :( bye bye nice models. Do you think it would be a good idea to update the Quickstart guide now to not use the Data Mapper pattern and use doctrine instead? I would strongly disagree with that move. I think ZF has always offered 2 solid solutions to modeling: use our Data classes (Table Row, etc) to build out a proper model, OR use a 3rd Party ORM framework- like Doctrine. At ZendCon, i've heard more than one person say "This is the way modeling should be done" after seeing matthew's talk on http://www.slideshare.net/weierophinney/architecting-your-models If a project doesn't have the resources to model their data like that, or they need to leverage the Doctrine ecosystem to get a project done in time. But in the most ideal world (where resources are not an issue), I too think that this presentation shows how things should be done. That said, I think the quickstart should show both options, but focus on the Data Mapper, Service Layer stuff. -ralph
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I'd be very interested to have a look at your resource as I am just prototyping now for quite a large system now so would be great to have a look at what you have done. Thanks On 30 Oct 2009, at 12:03, "A.J. Brown" wrote: I use Zend Framework and Doctrine bundled together quiet frequently. If I can be of any assistance in this new direction, I'm most certainly interested in helping. In the short term, I have some code to boot Doctrine is a Zend_Application_Resource with configuration, if anyone is interested. On Fri, Oct 30, 2009 at 7:07 AM, Matthew Weier O'Phinney wrote: -- Georgy Turevich wrote (on Friday, 30 October 2009, 11:31 AM +0300): I have not understood. The component will be developed by other people? Or it is discontinue for ever? Discontinued. All development was being done basically by Benjamin himself, and my team is simply too small for me to provide him much additional support without having it affect other projects. We have considered in the past writing an ORM, and the conclusion has always been that we do not have either enough expertise or resources on our team to undertake it. I was willing to let it be a community effort, but it would have taken a dedicated team of volunteers (a) to make it happen in a reasonable time frame, and (b) to provide ongoing support for it. Benjamin got to a point where he realized he'd finished about 50% of functionality, and likely had another 4-6 months before it was releasable. At that point, we'd be gearing up for ZF 2.0, which would mean he'd need to start rewriting to make use of PHP 5.3 features. It was simply a very daunting task, and one he wasn't getting much help with. Additionally, there's the fact that Doctrine is becoming a key part of the greater PHP ecosystem. Agavi and Symfony ship with it. I've seen tutorials for using it with CodeIgniter, Cake (and the new offshoot, Lithium), and of course ZF. Considering that many developers will be using it in other projects, it makes for a natural migration point -- migrate your models from one framework to another in order to make use of a different MVC or components. It simply makes sense *not* to reinvent the wheel here, and instead spend some time doing formal integration with Doctrine in order to leverage its community of developers. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ -- A.J. Brown web | http://ajbrown.org phone | (937) 660-3969
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hello, Sorry about that, but I was a little bit skeptical about Zend_Entity in the first place. Mainly, as known now, because there was only one person actually doing it and therefore it seemed literally impossible to complete it in a reasonable amount of time and maintain a good code quality in the future. That's why I chose Doctrine a while back. I had a few talks about the fact that zf tries to have too much components in it (that's another topic) and always believed that it can replace some of them by 3rdparty ones. The fact, that Doctrine is chosen is wonderful for me - two brilliant libraries with good developers teams on both sides also. I have been using it with zf for quite a long time and tried a lot of different components with it (Models, Forms, Services, Paginator, Auth+Acl, etc.) so I'm up to contribute to this proposal when it becomes available. -- Juozas Kaziukėnas (juo...@juokaz.com) Aš internete - JuoKaz (http://www.juokaz.com) On Fri, Oct 30, 2009 at 11:07 AM, Matthew Weier O'Phinney wrote: > -- Georgy Turevich wrote > (on Friday, 30 October 2009, 11:31 AM +0300): > > I have not understood. The component will be developed by other people? > Or it > > is discontinue for ever? > > Discontinued. > > All development was being done basically by Benjamin himself, and my > team is simply too small for me to provide him much additional support > without having it affect other projects. We have considered in the past > writing an ORM, and the conclusion has always been that we do not have > either enough expertise or resources on our team to undertake it. I was > willing to let it be a community effort, but it would have taken a > dedicated team of volunteers (a) to make it happen in a reasonable time > frame, and (b) to provide ongoing support for it. > > Benjamin got to a point where he realized he'd finished about 50% of > functionality, and likely had another 4-6 months before it was > releasable. At that point, we'd be gearing up for ZF 2.0, which would > mean he'd need to start rewriting to make use of PHP 5.3 features. It > was simply a very daunting task, and one he wasn't getting much help > with. > > Additionally, there's the fact that Doctrine is becoming a key part of > the greater PHP ecosystem. Agavi and Symfony ship with it. I've seen > tutorials for using it with CodeIgniter, Cake (and the new offshoot, > Lithium), and of course ZF. Considering that many developers will be > using it in other projects, it makes for a natural migration point -- > migrate your models from one framework to another in order to make use > of a different MVC or components. It simply makes sense *not* to > reinvent the wheel here, and instead spend some time doing formal > integration with Doctrine in order to leverage its community of > developers. > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ >
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I use Zend Framework and Doctrine bundled together quiet frequently. If I can be of any assistance in this new direction, I'm most certainly interested in helping. In the short term, I have some code to boot Doctrine is a Zend_Application_Resource with configuration, if anyone is interested. On Fri, Oct 30, 2009 at 7:07 AM, Matthew Weier O'Phinney wrote: > -- Georgy Turevich wrote > (on Friday, 30 October 2009, 11:31 AM +0300): >> I have not understood. The component will be developed by other people? Or it >> is discontinue for ever? > > Discontinued. > > All development was being done basically by Benjamin himself, and my > team is simply too small for me to provide him much additional support > without having it affect other projects. We have considered in the past > writing an ORM, and the conclusion has always been that we do not have > either enough expertise or resources on our team to undertake it. I was > willing to let it be a community effort, but it would have taken a > dedicated team of volunteers (a) to make it happen in a reasonable time > frame, and (b) to provide ongoing support for it. > > Benjamin got to a point where he realized he'd finished about 50% of > functionality, and likely had another 4-6 months before it was > releasable. At that point, we'd be gearing up for ZF 2.0, which would > mean he'd need to start rewriting to make use of PHP 5.3 features. It > was simply a very daunting task, and one he wasn't getting much help > with. > > Additionally, there's the fact that Doctrine is becoming a key part of > the greater PHP ecosystem. Agavi and Symfony ship with it. I've seen > tutorials for using it with CodeIgniter, Cake (and the new offshoot, > Lithium), and of course ZF. Considering that many developers will be > using it in other projects, it makes for a natural migration point -- > migrate your models from one framework to another in order to make use > of a different MVC or components. It simply makes sense *not* to > reinvent the wheel here, and instead spend some time doing formal > integration with Doctrine in order to leverage its community of > developers. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- A.J. Brown web | http://ajbrown.org phone | (937) 660-3969
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- Georgy Turevich wrote (on Friday, 30 October 2009, 11:31 AM +0300): > I have not understood. The component will be developed by other people? Or it > is discontinue for ever? Discontinued. All development was being done basically by Benjamin himself, and my team is simply too small for me to provide him much additional support without having it affect other projects. We have considered in the past writing an ORM, and the conclusion has always been that we do not have either enough expertise or resources on our team to undertake it. I was willing to let it be a community effort, but it would have taken a dedicated team of volunteers (a) to make it happen in a reasonable time frame, and (b) to provide ongoing support for it. Benjamin got to a point where he realized he'd finished about 50% of functionality, and likely had another 4-6 months before it was releasable. At that point, we'd be gearing up for ZF 2.0, which would mean he'd need to start rewriting to make use of PHP 5.3 features. It was simply a very daunting task, and one he wasn't getting much help with. Additionally, there's the fact that Doctrine is becoming a key part of the greater PHP ecosystem. Agavi and Symfony ship with it. I've seen tutorials for using it with CodeIgniter, Cake (and the new offshoot, Lithium), and of course ZF. Considering that many developers will be using it in other projects, it makes for a natural migration point -- migrate your models from one framework to another in order to make use of a different MVC or components. It simply makes sense *not* to reinvent the wheel here, and instead spend some time doing formal integration with Doctrine in order to leverage its community of developers. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Benjamin Eberlei wrote: I just want to inform everyone that I will discontinue development on Zend Entity and in return invest time to integrate Doctrine with Zend Framework on a large scale. Excellent decision! Though I know writing a good ORM is a very fun job and I am sure you will miss it, I am very happy with this, because Yet Another ORM isn't really what we needed, imho :-) I would like to help, but I'm not sure how. drm / Gerard
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I have not understood. The component will be developed by other people? Or it is discontinue for ever?
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/29 Benjamin Eberlei : > Hello Keith, > > you should take a look at Doctrine 2. As Zend Entity it implements the JPA > specification and is a true data mapper with models decoupled from Database > completly. Looking now, I didnt think it was nearing release yet last time I looked it seemed far off, time obviously passes too quickly hehe Wish I didnt have to upgrade to PHP 5.3 to use it though, working on legacy systems means its a lot of work! But too be fair it needs to be done anyway :) When are the integration discussions happening? Thanks for your work on Zend_Entity its been informative watching it develop anyway :) > > greetings, > Benjamin > > On Thursday 29 October 2009 09:19:50 pm keith Pope wrote: >> 29 Matthew Weier O'Phinney : >> > -- Antonio José García Lagar wrote >> > >> > (on Thursday, 29 October 2009, 08:17 PM +0100): >> >> 2009/10/29 Matthew Weier O'Phinney >> >> >> >> >> >> Ideally, we'll have both Doctrine 1.x and 2.x integration, for this >> >> very reason - though likely as separate implementations (Zend_Doctrine, >> >> Zend_Doctrine2). There are some commonalities between them that we can >> >> leverage immediately (application resources, in particular), and others >> >> that will require more collaboration between the two projects (e.g., >> >> shared cache objects and loggers, etc.). >> >> I must say its a shame that ZE is going, I thought it was too bigger a >> project for one person, not fair asking for that much commitment from >> anyone. >> >> Time to go back to using Doctrine then :( bye bye nice models. >> >> Do you think it would be a good idea to update the Quickstart guide >> now to not use the Data Mapper pattern and use doctrine instead? >> >> >> Do you think this will be available for the 1.10 release? >> >> >> >> You should update the roadmap at >> >> http://framework.zend.com/roadmap/1.10.0 >> >> >> >> I hope to see an early proposal to start to help. >> > >> > We're in the very early stages of gathering requirements; I honestly >> > don't see it being ready for 1.10. >> > >> > -- >> > Matthew Weier O'Phinney >> > Project Lead | matt...@zend.com >> > Zend Framework | http://framework.zend.com/ > > > -- > Benjamin Eberlei > http://www.beberlei.de > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hello Keith, you should take a look at Doctrine 2. As Zend Entity it implements the JPA specification and is a true data mapper with models decoupled from Database completly. greetings, Benjamin On Thursday 29 October 2009 09:19:50 pm keith Pope wrote: > 29 Matthew Weier O'Phinney : > > -- Antonio José García Lagar wrote > > > > (on Thursday, 29 October 2009, 08:17 PM +0100): > >> 2009/10/29 Matthew Weier O'Phinney > >> > >> > >> Ideally, we'll have both Doctrine 1.x and 2.x integration, for this > >> very reason - though likely as separate implementations (Zend_Doctrine, > >> Zend_Doctrine2). There are some commonalities between them that we can > >> leverage immediately (application resources, in particular), and others > >> that will require more collaboration between the two projects (e.g., > >> shared cache objects and loggers, etc.). > > I must say its a shame that ZE is going, I thought it was too bigger a > project for one person, not fair asking for that much commitment from > anyone. > > Time to go back to using Doctrine then :( bye bye nice models. > > Do you think it would be a good idea to update the Quickstart guide > now to not use the Data Mapper pattern and use doctrine instead? > > >> Do you think this will be available for the 1.10 release? > >> > >> You should update the roadmap at > >> http://framework.zend.com/roadmap/1.10.0 > >> > >> I hope to see an early proposal to start to help. > > > > We're in the very early stages of gathering requirements; I honestly > > don't see it being ready for 1.10. > > > > -- > > Matthew Weier O'Phinney > > Project Lead| matt...@zend.com > > Zend Framework | http://framework.zend.com/ -- Benjamin Eberlei http://www.beberlei.de
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- keith Pope wrote (on Thursday, 29 October 2009, 08:19 PM +): > 29 Matthew Weier O'Phinney : > > -- Antonio José García Lagar wrote > > (on Thursday, 29 October 2009, 08:17 PM +0100): > >> 2009/10/29 Matthew Weier O'Phinney > >> > >> > >> Ideally, we'll have both Doctrine 1.x and 2.x integration, for this > >> very > >> reason - though likely as separate implementations (Zend_Doctrine, > >> Zend_Doctrine2). There are some commonalities between them that we can > >> leverage immediately (application resources, in particular), and others > >> that will require more collaboration between the two projects (e.g., > >> shared cache objects and loggers, etc.). > > I must say its a shame that ZE is going, I thought it was too bigger a > project for one person, not fair asking for that much commitment from > anyone. > > Time to go back to using Doctrine then :( bye bye nice models. Take a look at Doctrine 2 -- Zend_Entity and Doctrine 2 shared a very similar design, and the models are completely de-coupled. > Do you think it would be a good idea to update the Quickstart guide > now to not use the Data Mapper pattern and use doctrine instead? Yes, once we have integration in place. ;) -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
29 Matthew Weier O'Phinney : > -- Antonio José García Lagar wrote > (on Thursday, 29 October 2009, 08:17 PM +0100): >> 2009/10/29 Matthew Weier O'Phinney >> >> >> Ideally, we'll have both Doctrine 1.x and 2.x integration, for this very >> reason - though likely as separate implementations (Zend_Doctrine, >> Zend_Doctrine2). There are some commonalities between them that we can >> leverage immediately (application resources, in particular), and others >> that will require more collaboration between the two projects (e.g., >> shared cache objects and loggers, etc.). I must say its a shame that ZE is going, I thought it was too bigger a project for one person, not fair asking for that much commitment from anyone. Time to go back to using Doctrine then :( bye bye nice models. Do you think it would be a good idea to update the Quickstart guide now to not use the Data Mapper pattern and use doctrine instead? >> >> >> Do you think this will be available for the 1.10 release? >> >> You should update the roadmap at http://framework.zend.com/roadmap/1.10.0 >> >> I hope to see an early proposal to start to help. > > We're in the very early stages of gathering requirements; I honestly > don't see it being ready for 1.10. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- Antonio José García Lagar wrote (on Thursday, 29 October 2009, 08:17 PM +0100): > 2009/10/29 Matthew Weier O'Phinney > > > Ideally, we'll have both Doctrine 1.x and 2.x integration, for this very > reason - though likely as separate implementations (Zend_Doctrine, > Zend_Doctrine2). There are some commonalities between them that we can > leverage immediately (application resources, in particular), and others > that will require more collaboration between the two projects (e.g., > shared cache objects and loggers, etc.). > > > Do you think this will be available for the 1.10 release? > > You should update the roadmap at http://framework.zend.com/roadmap/1.10.0 > > I hope to see an early proposal to start to help. We're in the very early stages of gathering requirements; I honestly don't see it being ready for 1.10. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- prodigitalson wrote (on Thursday, 29 October 2009, 12:04 PM -0700): > I dont know if its even possible but id really like to see some general > abstraction for ORM integration that these would be based on... Just to make > it easier to integrate Propel for instance. > > Granted this would have to be pretty abstract given vendor differences - or > even differences in major versions of the same software. Im just thinking > that if i want to integrate ORM XYZ, i should general > interfaces/abstractions for Model Builders, Form Builders, Loggers and what > not to program to make the process just a little less daunting. While some of this may be abstractable, the fact is that even between Doctrine and Doctrine 2 the structure of the project changed fairly significantly. We may be able to leverage some of the work/ideas from Symfony (which supports both), but even there, I seem to recall that the configuration is quite different between the projects. Additionally, for things such as model/form builders, these would be handled by the ORM layer; at most, we might have a Zend_Tool provider that proxies to the Doctrine CLI tooling (which can be invoked via class methods). Loggers, etc., are typically project specific -- but one of the points where we would like more direct integration. If you or others want to see additional ORM solutions, write up proposals soon, so we can start determining if there are enough commonalities to warrant an abstraction layer within ZF. > Sorry to see Zend_Entity go, but I readily welcome Doctrine :-) > > > weierophinney wrote: > > > > -- Antonio José García Lagar wrote > > (on Thursday, 29 October 2009, 07:24 PM +0100): > >> I'm so sorry for this decision but otherwise I know this was a hard work > >> that > >> you have done mostly alone. > >> > >> Although the project is not finished, I congratulate you: your work has > >> been > >> excellent. > >> > >> Do you plan to integrate Doctrine 1.x with ZF? I think that I'm not the > >> only > >> one tied to PHP 5.2. I hope to help with this. > > > > Ideally, we'll have both Doctrine 1.x and 2.x integration, for this very > > reason - though likely as separate implementations (Zend_Doctrine, > > Zend_Doctrine2). There are some commonalities between them that we can > > leverage immediately (application resources, in particular), and others > > that will require more collaboration between the two projects (e.g., > > shared cache objects and loggers, etc.). > > > > -- > > Matthew Weier O'Phinney > > Project Lead| matt...@zend.com > > Zend Framework | http://framework.zend.com/ > > > > > > -- > View this message in context: > http://www.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp26117819p26118942.html > Sent from the Zend Framework mailing list archive at Nabble.com. > -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/29 Matthew Weier O'Phinney > > Ideally, we'll have both Doctrine 1.x and 2.x integration, for this very > reason - though likely as separate implementations (Zend_Doctrine, > Zend_Doctrine2). There are some commonalities between them that we can > leverage immediately (application resources, in particular), and others > that will require more collaboration between the two projects (e.g., > shared cache objects and loggers, etc.). > > Do you think this will be available for the 1.10 release? You should update the roadmap at http://framework.zend.com/roadmap/1.10.0 I hope to see an early proposal to start to help. -- Antonio José García Lagar http://aj.garcialagar.es a...@garcialagar.es
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I dont know if its even possible but id really like to see some general abstraction for ORM integration that these would be based on... Just to make it easier to integrate Propel for instance. Granted this would have to be pretty abstract given vendor differences - or even differences in major versions of the same software. Im just thinking that if i want to integrate ORM XYZ, i should general interfaces/abstractions for Model Builders, Form Builders, Loggers and what not to program to make the process just a little less daunting. Sorry to see Zend_Entity go, but I readily welcome Doctrine :-) weierophinney wrote: > > -- Antonio José García Lagar wrote > (on Thursday, 29 October 2009, 07:24 PM +0100): >> I'm so sorry for this decision but otherwise I know this was a hard work >> that >> you have done mostly alone. >> >> Although the project is not finished, I congratulate you: your work has >> been >> excellent. >> >> Do you plan to integrate Doctrine 1.x with ZF? I think that I'm not the >> only >> one tied to PHP 5.2. I hope to help with this. > > Ideally, we'll have both Doctrine 1.x and 2.x integration, for this very > reason - though likely as separate implementations (Zend_Doctrine, > Zend_Doctrine2). There are some commonalities between them that we can > leverage immediately (application resources, in particular), and others > that will require more collaboration between the two projects (e.g., > shared cache objects and loggers, etc.). > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ > > -- View this message in context: http://www.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp26117819p26118942.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- Antonio José García Lagar wrote (on Thursday, 29 October 2009, 07:24 PM +0100): > I'm so sorry for this decision but otherwise I know this was a hard work that > you have done mostly alone. > > Although the project is not finished, I congratulate you: your work has been > excellent. > > Do you plan to integrate Doctrine 1.x with ZF? I think that I'm not the only > one tied to PHP 5.2. I hope to help with this. Ideally, we'll have both Doctrine 1.x and 2.x integration, for this very reason - though likely as separate implementations (Zend_Doctrine, Zend_Doctrine2). There are some commonalities between them that we can leverage immediately (application resources, in particular), and others that will require more collaboration between the two projects (e.g., shared cache objects and loggers, etc.). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I'm so sorry for this decision but otherwise I know this was a hard work that you have done mostly alone. Although the project is not finished, I congratulate you: your work has been excellent. Do you plan to integrate Doctrine 1.x with ZF? I think that I'm not the only one tied to PHP 5.2. I hope to help with this. -- Antonio José García Lagar http://aj.garcialagar.es a...@garcialagar.es