subject:"\[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

2009-11-25 Thread drm


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

2009-11-25 Thread Benjamin Eberlei


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
arie.benic...@gmail.com 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,


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

2009-11-25 Thread drm


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 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
 arie.benic...@gmail.com 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

2009-11-25 Thread Pádraic Brady

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 arie.benic...@gmail.com
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 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

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 RD 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 arie.benic...@gmail.com
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

2009-11-25 Thread Pádraic Brady

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 arie.benic...@gmail.com
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 RD 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 arie.benic...@gmail.com
 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

2009-11-25 Thread Matthew Weier O'Phinney

-- Arié Bénichou arie.benic...@gmail.com 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

2009-11-25 Thread Matthew Weier O'Phinney

-- Arié Bénichou arie.benic...@gmail.com 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
arie.benic...@gmail.com 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

2009-11-25 Thread Matthew Ratzloff

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
matt...@zend.comwrote:

beberlei wrote:

Hello,

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
arie.benic...@gmail.com 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

2009-11-04 Thread A.J. Brown

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
piccoloprincipeazzu...@gmail.com 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

2009-11-04 Thread Matthew Ratzloff

Would be ZendX_Doctrine_AuthAdapter (or something), wouldn't it?

-Matt

On Wed, Nov 4, 2009 at 1:10 PM, A.J. Brown fynw...@gmail.com 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
 piccoloprincipeazzu...@gmail.com 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

2009-10-31 Thread keith Pope

2009/10/31 Pádraic Brady padraic.br...@yahoo.com:
 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 mute.p...@googlemail.com
 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 matt...@zend.com:
 -- keith Pope mute.p...@googlemail.com wrote
 (on Friday, 30 October 2009, 04:43 PM +):
 2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
  -- keith Pope mute.p...@googlemail.com wrote
  (on Friday, 30 October 2009, 04:02 PM +):
   2009/10/30 Ralph Schindler ralph.schind...@zend.com :
   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

2009/10/29 Benjamin Eberlei kont...@beberlei.de:
 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 matt...@zend.com:
  -- Antonio José García Lagar a...@garcialagar.es wrote
 
  (on Thursday, 29 October 2009, 08:17 PM +0100):
  2009/10/29 Matthew Weier O'Phinney matt...@zend.com
 
 
      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

2009-10-30 Thread Georgy Turevich

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-30 Thread drm


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

-- Georgy Turevich georgy.turev...@gmail.com 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

2009-10-30 Thread A.J. Brown

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
matt...@zend.com wrote:
 -- Georgy Turevich georgy.turev...@gmail.com 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

2009-10-30 Thread Juozas

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
matt...@zend.comwrote:

 -- Georgy Turevich georgy.turev...@gmail.com 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

2009-10-30 Thread Daniel Latter

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 fynw...@gmail.com 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
matt...@zend.com wrote:

-- Georgy Turevich georgy.turev...@gmail.com 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

2009-10-30 Thread 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.


-ralph

Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration

2009/10/30 Ralph Schindler ralph.schind...@zend.com:


 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

2009-10-30 Thread drm


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

-- keith Pope mute.p...@googlemail.com wrote
(on Friday, 30 October 2009, 04:02 PM +):
 2009/10/30 Ralph Schindler ralph.schind...@zend.com :
   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

2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
 -- keith Pope mute.p...@googlemail.com wrote
 (on Friday, 30 October 2009, 04:02 PM +):
 2009/10/30 Ralph Schindler ralph.schind...@zend.com :
   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 mute.p...@googlemail.com wrote
(on Friday, 30 October 2009, 04:43 PM +):
 2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
  -- keith Pope mute.p...@googlemail.com wrote
  (on Friday, 30 October 2009, 04:02 PM +):
   2009/10/30 Ralph Schindler ralph.schind...@zend.com :
   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 matt...@zend.com:
 -- keith Pope mute.p...@googlemail.com wrote
 (on Friday, 30 October 2009, 04:43 PM +):
 2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
  -- keith Pope mute.p...@googlemail.com wrote
  (on Friday, 30 October 2009, 04:02 PM +):
   2009/10/30 Ralph Schindler ralph.schind...@zend.com :
   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

2009-10-30 Thread A.J. Brown

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
matt...@zend.com wrote:
 -- keith Pope mute.p...@googlemail.com wrote
 (on Friday, 30 October 2009, 04:43 PM +):
 2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
  -- keith Pope mute.p...@googlemail.com wrote
  (on Friday, 30 October 2009, 04:02 PM +):
   2009/10/30 Ralph Schindler ralph.schind...@zend.com :
   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 Thread Juozas

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 fynw...@gmail.com 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
 matt...@zend.com wrote:
  -- keith Pope mute.p...@googlemail.com wrote
  (on Friday, 30 October 2009, 04:43 PM +):
  2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
   -- keith Pope mute.p...@googlemail.com wrote
   (on Friday, 30 October 2009, 04:02 PM +):
2009/10/30 Ralph Schindler ralph.schind...@zend.com :
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

-- keith Pope mute.p...@googlemail.com wrote
(on Friday, 30 October 2009, 07:19 PM +):
 2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
  -- keith Pope mute.p...@googlemail.com wrote
  (on Friday, 30 October 2009, 04:43 PM +):
  2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
   -- keith Pope mute.p...@googlemail.com wrote
   (on Friday, 30 October 2009, 04:02 PM +):
2009/10/30 Ralph Schindler ralph.schind...@zend.com :
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

2009-10-30 Thread 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.

My 2c :)

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative






From: keith Pope mute.p...@googlemail.com
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 matt...@zend.com:
 -- keith Pope mute.p...@googlemail.com wrote
 (on Friday, 30 October 2009, 04:43 PM +):
 2009/10/30 Matthew Weier O'Phinney matt...@zend.com:
  -- keith Pope mute.p...@googlemail.com wrote
  (on Friday, 30 October 2009, 04:02 PM +):
   2009/10/30 Ralph Schindler ralph.schind...@zend.com :
   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

[fw-general] Discontinuing Zend Entity in favour of Doctrine integration

2009-10-29 Thread Benjamin Eberlei

Hello everyone,

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. I changed my mind for several reasons

1. It drains up all my free time and I got quite a blockade from it.
2. I am the only major contributor, and compared to Doctrine 2 the feature set
   is probably only at 50-60%.
3. A realistic estimate for a first production ready release of Zend Entity
   would be 4-6 month, a time where ZF is probably starting to think heavily
   of PHP 5.3 adoption in regards with the 2.0 release. This is not a good
   time for another major component that starts of in 1.x

I've discussed the decision with Matthew, and while we both liked
the idea of having a native ORM in ZF, we also both feel that
helping improve an existing project and providing good integration
with it will likely be better for the entire ecosystem. If you are
interested, please contact us to help us start planning this
initiative.

I hope this step isn't a disappointment to anyone, personally I had lots of
fun developing Zend Entity and learnt quite a bit that I can hopefully
contribute to Doctrine also. Also special thanks to all those that offered
help, feedback and contributions.

greetings,
Benjamin
-- 
Benjamin Eberlei
http://www.beberlei.de

Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration

2009-10-29 Thread Antonio José García Lagar

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

Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration

-- Antonio José García Lagar a...@garcialagar.es 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

2009-10-29 Thread prodigitalson

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 a...@garcialagar.es 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

2009-10-29 Thread Antonio José García Lagar

2009/10/29 Matthew Weier O'Phinney matt...@zend.com


 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

-- prodigitalson ant.cunning...@gmail.com 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.

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:

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.

--
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

-- Antonio José García Lagar a...@garcialagar.es wrote
(on Thursday, 29 October 2009, 08:17 PM +0100):
 2009/10/29 Matthew Weier O'Phinney matt...@zend.com
 
 
 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

2009-10-29 Thread keith Pope

29 Matthew Weier O'Phinney matt...@zend.com:
 -- Antonio José García Lagar a...@garcialagar.es wrote
 (on Thursday, 29 October 2009, 08:17 PM +0100):
 2009/10/29 Matthew Weier O'Phinney matt...@zend.com


     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