Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I think Matthew is pointing out that there have always been doubts about utilising a DI container in light weight languages like PHP, Python, and Ruby. In essence, it's remarkably hard to create a valid use case for a DI container. You can create any number of artificial examples, but the light weightedness of PHP, it's tolerance for loose coupling, and the minimal code it generates (all reasons why we use it) make using DI overkill - probably in 95% or more of the common uses for PHP. There are some interesting case studies in Ruby if you go looking where individuals have experiemented in writing a DI container/framework for Ruby. Ruby has several Di containers/frameworks - nearly all them are classified as dormant. Ruby has one very neat thing over PHP - you can overload object instantiation. This is not to say a DI container is useless or meaningless, but the classical concept of a DI container from Java or C# is only marginally useful in PHP. In most respects all you really need is a little substitution and light mapping. If that's the goal of any future DI work in ZF, then please, fire on all cylinders. Whether that would qualify as a DI container or not is anyone's guess ;). Once you start accumulating more features, more complex mapping, and more classical injection methods - then it will bury itself into oblivion as an overarchitected mess 99% of PHP developers just do not need. My 2c :) Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative From: keith Pope To: fw-general@lists.zend.com Sent: Fri, October 30, 2009 7:19:25 PM Subject: Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration 2009/10/30 Matthew Weier O'Phinney : > -- keith Pope wrote > (on Friday, 30 October 2009, 04:43 PM +): >> 2009/10/30 Matthew Weier O'Phinney : >> > -- keith Pope wrote >> > (on Friday, 30 October 2009, 04:02 PM +): >> > > 2009/10/30 Ralph Schindler : >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine >> > > integration is there any reason to keep Zend_Db? >> > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using >> > Doctrine, and for many one-off types of applications (single tables, or >> > multiple tables with no relations, etc.), having Zend_Db around will >> > continue to be essential. Additionally, one aspect I'd like to explore >> > with the Doctrine folks is potentially allowing Zend_Db adapters as >> > Doctrine RDBMS adapters; this would provide some very interesting >> > integration points. >> >> Sounds interesting I look forward to seeing this initiative develop >> further, I would be happy to help in any way I can :) >> >> Once we have the integration especially with doctrine 2 would there be >> any further plans to look at things like dependency injection, >> criteria objects and repositories or any other DDD tools? To me having >> a full suite of tools like this would be a great long term goal? > > DI is something we're already planning for -- you'll note the "unified > constructor" pattern in all new components. Whether or not we'll have a > DI _container_ is another question; I'm not entirely convinced DI > containers have a good place in stateless applications, but I'll let > Ralph talk more to that point. :) That is an interesting point, I dont quite understand how state affects object dependencies or is the container an unnecessary overhead when you are working in a limited state environment? Something I may have to ponder > > As for criteria objects, we've just approved another of Ben's > components, some extensions to Zend_Db_Expr. One aspect I particularly > like with it is that, combined with Zend_Db_Select, we are getting to a > point where we have an almost complete criteria object for select > operations. This could certainly be adapted for use with DDD fairly > easily. Regarding repositories, Zend_Application_Bootstrap actually > already acts as one in many ways -- though we may do more with this > and/or service locators for 2.0. > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- http://www.thepopeisdead.com
Re: [fw-general] memory limit exhausted when trying to bootstap a module
On Fri, Oct 30, 2009 at 10:51 PM, Matt Cockayne wrote: > > Hi. > I'm trying to bootstrap a module using the modules resource. However when > ever I try I hit my memory limit. I have increased the limit to in excess of > 500M and still getting problems. > > This happens even whenthe module I'm trying to load is just outputting some > html. > > As soon as I disable the modules resource everything is fine. > > Has anyone else had these problems. Or can someone point me in the right > direction of how to fix this. > > I'm using v1.9.4 of the framework and am using the instructions in the ref > guide I'd suggest you install Xdebug and enable the profiler to track memory usage and execution time. Otherwise it's hard to troubleshoot your issue. Xdebug is also useful since it provides a full stack trace. I know that we are running with 128 MB currently and it's going pretty well. I can't imagine you would really need 500 MB to satisfy your app. I'm (only) guessing, but maybe you caught a loop somewhere or a giant result set, or something similar. Till
Re: [fw-general] memory limit exhausted when trying to bootstap a module
What is your memory limit set to? PHP's default is set terribly low (around 8MB I believe). I'm not sure what the recommended memory limit is for a basic ZF application but I've had good luck with 64MB and 128MB. -- Hector On Fri, Oct 30, 2009 at 2:51 PM, Matt Cockayne wrote: > > Hi. > I'm trying to bootstrap a module using the modules resource. However when > ever I try I hit my memory limit. I have increased the limit to in excess > of > 500M and still getting problems. > > This happens even whenthe module I'm trying to load is just outputting some > html. > > As soon as I disable the modules resource everything is fine. > > Has anyone else had these problems. Or can someone point me in the right > direction of how to fix this. > > I'm using v1.9.4 of the framework and am using the instructions in the ref > guide > -- > View this message in context: > http://old.nabble.com/memory-limit-exhausted-when-trying-to-bootstap-a-module-tp26137402p26137402.html > Sent from the Zend Framework mailing list archive at Nabble.com. > >
[fw-general] memory limit exhausted when trying to bootstap a module
Hi. I'm trying to bootstrap a module using the modules resource. However when ever I try I hit my memory limit. I have increased the limit to in excess of 500M and still getting problems. This happens even whenthe module I'm trying to load is just outputting some html. As soon as I disable the modules resource everything is fine. Has anyone else had these problems. Or can someone point me in the right direction of how to fix this. I'm using v1.9.4 of the framework and am using the instructions in the ref guide -- View this message in context: http://old.nabble.com/memory-limit-exhausted-when-trying-to-bootstap-a-module-tp26137402p26137402.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- keith Pope wrote (on Friday, 30 October 2009, 07:19 PM +): > 2009/10/30 Matthew Weier O'Phinney : > > -- keith Pope wrote > > (on Friday, 30 October 2009, 04:43 PM +): > >> 2009/10/30 Matthew Weier O'Phinney : > >> > -- keith Pope wrote > >> > (on Friday, 30 October 2009, 04:02 PM +): > >> > > 2009/10/30 Ralph Schindler : > >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine > >> > > integration is there any reason to keep Zend_Db? > >> > > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using > >> > Doctrine, and for many one-off types of applications (single tables, or > >> > multiple tables with no relations, etc.), having Zend_Db around will > >> > continue to be essential. Additionally, one aspect I'd like to explore > >> > with the Doctrine folks is potentially allowing Zend_Db adapters as > >> > Doctrine RDBMS adapters; this would provide some very interesting > >> > integration points. > >> > >> Sounds interesting I look forward to seeing this initiative develop > >> further, I would be happy to help in any way I can :) > >> > >> Once we have the integration especially with doctrine 2 would there be > >> any further plans to look at things like dependency injection, > >> criteria objects and repositories or any other DDD tools? To me having > >> a full suite of tools like this would be a great long term goal? > > > > DI is something we're already planning for -- you'll note the "unified > > constructor" pattern in all new components. Whether or not we'll have a > > DI _container_ is another question; I'm not entirely convinced DI > > containers have a good place in stateless applications, but I'll let > > Ralph talk more to that point. :) > > That is an interesting point, I dont quite understand how state > affects object dependencies or is the container an unnecessary > overhead when you are working in a limited state environment? > Something I may have to ponder There are two things: * Depending on the architecture of the DI container, you may end up with many objects instantiated which are never used -- leading to overhead. DI containers evolved in large part in Java, where you want to preload everything, as eventually everything will be loaded anyways. This is not true of PHP applications, where often what is loaded is determined by the execution path. * Complexity of setup. When you have a DI container, you often have large, complicated dependency setups that are difficult to understand unless you understand the entire application architecture. This can make learning the framework and/or individual applications much more difficult -- as well as determining where and when in the configuration to make changes. For examples, look at tomcat or any atlassian tool (not to dis the tools, but they all exhibit very complex dependency setups). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi, Also, this is my resource which i use: http://pastebin.com/d207ac465 Just add to config: resources.database.connection_string = "mysql://user:p...@localhost/db" resources.database.compiled = false; use compiled version of Doctrine It enables autoloading for models and tables, utf-8 for connection, validation on save and dql callbacks. P.S. It expects Doctrine to be in library/Doctrine/Doctrine.php. It is like that because i use svn:externals to update doctrine and don't want to have it straight in my library folder -- Juozas Kaziukėnas (juo...@juokaz.com) Aš internete - JuoKaz (http://www.juokaz.com) On Fri, Oct 30, 2009 at 7:30 PM, A.J. Brown wrote: > For those that are interested in my resource class: > > http://gist.github.com/222645 > > I'm also working on making a resource for the CLI components, so that > you can do deployments from within your Zend Framework application. > For example, if the environment is a testing server, the application > will automatically do a build-all-reload. Or perhaps the application > will automatically run migrations when new ones are detected. > > This is just a starting point. > > On Fri, Oct 30, 2009 at 1:23 PM, Matthew Weier O'Phinney > wrote: > > -- keith Pope wrote > > (on Friday, 30 October 2009, 04:43 PM +): > >> 2009/10/30 Matthew Weier O'Phinney : > >> > -- keith Pope wrote > >> > (on Friday, 30 October 2009, 04:02 PM +): > >> > > 2009/10/30 Ralph Schindler : > >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine > >> > > integration is there any reason to keep Zend_Db? > >> > > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be > using > >> > Doctrine, and for many one-off types of applications (single tables, > or > >> > multiple tables with no relations, etc.), having Zend_Db around will > >> > continue to be essential. Additionally, one aspect I'd like to explore > >> > with the Doctrine folks is potentially allowing Zend_Db adapters as > >> > Doctrine RDBMS adapters; this would provide some very interesting > >> > integration points. > >> > >> Sounds interesting I look forward to seeing this initiative develop > >> further, I would be happy to help in any way I can :) > >> > >> Once we have the integration especially with doctrine 2 would there be > >> any further plans to look at things like dependency injection, > >> criteria objects and repositories or any other DDD tools? To me having > >> a full suite of tools like this would be a great long term goal? > > > > DI is something we're already planning for -- you'll note the "unified > > constructor" pattern in all new components. Whether or not we'll have a > > DI _container_ is another question; I'm not entirely convinced DI > > containers have a good place in stateless applications, but I'll let > > Ralph talk more to that point. :) > > > > As for criteria objects, we've just approved another of Ben's > > components, some extensions to Zend_Db_Expr. One aspect I particularly > > like with it is that, combined with Zend_Db_Select, we are getting to a > > point where we have an almost complete criteria object for select > > operations. This could certainly be adapted for use with DDD fairly > > easily. Regarding repositories, Zend_Application_Bootstrap actually > > already acts as one in many ways -- though we may do more with this > > and/or service locators for 2.0. > > > > -- > > Matthew Weier O'Phinney > > Project Lead| matt...@zend.com > > Zend Framework | http://framework.zend.com/ > > > > > > -- > A.J. Brown > web | http://ajbrown.org > phone | (937) 660-3969 >
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
For those that are interested in my resource class: http://gist.github.com/222645 I'm also working on making a resource for the CLI components, so that you can do deployments from within your Zend Framework application. For example, if the environment is a testing server, the application will automatically do a build-all-reload. Or perhaps the application will automatically run migrations when new ones are detected. This is just a starting point. On Fri, Oct 30, 2009 at 1:23 PM, Matthew Weier O'Phinney wrote: > -- keith Pope wrote > (on Friday, 30 October 2009, 04:43 PM +): >> 2009/10/30 Matthew Weier O'Phinney : >> > -- keith Pope wrote >> > (on Friday, 30 October 2009, 04:02 PM +): >> > > 2009/10/30 Ralph Schindler : >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine >> > > integration is there any reason to keep Zend_Db? >> > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using >> > Doctrine, and for many one-off types of applications (single tables, or >> > multiple tables with no relations, etc.), having Zend_Db around will >> > continue to be essential. Additionally, one aspect I'd like to explore >> > with the Doctrine folks is potentially allowing Zend_Db adapters as >> > Doctrine RDBMS adapters; this would provide some very interesting >> > integration points. >> >> Sounds interesting I look forward to seeing this initiative develop >> further, I would be happy to help in any way I can :) >> >> Once we have the integration especially with doctrine 2 would there be >> any further plans to look at things like dependency injection, >> criteria objects and repositories or any other DDD tools? To me having >> a full suite of tools like this would be a great long term goal? > > DI is something we're already planning for -- you'll note the "unified > constructor" pattern in all new components. Whether or not we'll have a > DI _container_ is another question; I'm not entirely convinced DI > containers have a good place in stateless applications, but I'll let > Ralph talk more to that point. :) > > As for criteria objects, we've just approved another of Ben's > components, some extensions to Zend_Db_Expr. One aspect I particularly > like with it is that, combined with Zend_Db_Select, we are getting to a > point where we have an almost complete criteria object for select > operations. This could certainly be adapted for use with DDD fairly > easily. Regarding repositories, Zend_Application_Bootstrap actually > already acts as one in many ways -- though we may do more with this > and/or service locators for 2.0. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- A.J. Brown web | http://ajbrown.org phone | (937) 660-3969
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/30 Matthew Weier O'Phinney : > -- keith Pope wrote > (on Friday, 30 October 2009, 04:43 PM +): >> 2009/10/30 Matthew Weier O'Phinney : >> > -- keith Pope wrote >> > (on Friday, 30 October 2009, 04:02 PM +): >> > > 2009/10/30 Ralph Schindler : >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine >> > > integration is there any reason to keep Zend_Db? >> > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using >> > Doctrine, and for many one-off types of applications (single tables, or >> > multiple tables with no relations, etc.), having Zend_Db around will >> > continue to be essential. Additionally, one aspect I'd like to explore >> > with the Doctrine folks is potentially allowing Zend_Db adapters as >> > Doctrine RDBMS adapters; this would provide some very interesting >> > integration points. >> >> Sounds interesting I look forward to seeing this initiative develop >> further, I would be happy to help in any way I can :) >> >> Once we have the integration especially with doctrine 2 would there be >> any further plans to look at things like dependency injection, >> criteria objects and repositories or any other DDD tools? To me having >> a full suite of tools like this would be a great long term goal? > > DI is something we're already planning for -- you'll note the "unified > constructor" pattern in all new components. Whether or not we'll have a > DI _container_ is another question; I'm not entirely convinced DI > containers have a good place in stateless applications, but I'll let > Ralph talk more to that point. :) That is an interesting point, I dont quite understand how state affects object dependencies or is the container an unnecessary overhead when you are working in a limited state environment? Something I may have to ponder > > As for criteria objects, we've just approved another of Ben's > components, some extensions to Zend_Db_Expr. One aspect I particularly > like with it is that, combined with Zend_Db_Select, we are getting to a > point where we have an almost complete criteria object for select > operations. This could certainly be adapted for use with DDD fairly > easily. Regarding repositories, Zend_Application_Bootstrap actually > already acts as one in many ways -- though we may do more with this > and/or service locators for 2.0. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- keith Pope wrote (on Friday, 30 October 2009, 04:43 PM +): > 2009/10/30 Matthew Weier O'Phinney : > > -- keith Pope wrote > > (on Friday, 30 October 2009, 04:02 PM +): > > > 2009/10/30 Ralph Schindler : > > > Also will we be deprecating Zend_Db as if we have tight Doctrine > > > integration is there any reason to keep Zend_Db? > > > > There are plenty of reasons to keep Zend_Db. Not everyone will be using > > Doctrine, and for many one-off types of applications (single tables, or > > multiple tables with no relations, etc.), having Zend_Db around will > > continue to be essential. Additionally, one aspect I'd like to explore > > with the Doctrine folks is potentially allowing Zend_Db adapters as > > Doctrine RDBMS adapters; this would provide some very interesting > > integration points. > > Sounds interesting I look forward to seeing this initiative develop > further, I would be happy to help in any way I can :) > > Once we have the integration especially with doctrine 2 would there be > any further plans to look at things like dependency injection, > criteria objects and repositories or any other DDD tools? To me having > a full suite of tools like this would be a great long term goal? DI is something we're already planning for -- you'll note the "unified constructor" pattern in all new components. Whether or not we'll have a DI _container_ is another question; I'm not entirely convinced DI containers have a good place in stateless applications, but I'll let Ralph talk more to that point. :) As for criteria objects, we've just approved another of Ben's components, some extensions to Zend_Db_Expr. One aspect I particularly like with it is that, combined with Zend_Db_Select, we are getting to a point where we have an almost complete criteria object for select operations. This could certainly be adapted for use with DDD fairly easily. Regarding repositories, Zend_Application_Bootstrap actually already acts as one in many ways -- though we may do more with this and/or service locators for 2.0. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/30 Matthew Weier O'Phinney : > -- keith Pope wrote > (on Friday, 30 October 2009, 04:02 PM +): >> 2009/10/30 Ralph Schindler : >> > > Time to go back to using Doctrine then :( bye bye nice models. >> > > >> > > Do you think it would be a good idea to update the Quickstart guide >> > > now to not use the Data Mapper pattern and use doctrine instead? >> > >> > I would strongly disagree with that move. I think ZF has always offered 2 >> > solid solutions to modeling: use our Data classes (Table Row, etc) to build >> > out a proper model, OR use a 3rd Party ORM framework- like Doctrine. >> > >> > At ZendCon, i've heard more than one person say "This is the way modeling >> > should be done" after seeing matthew's talk on >> > >> > http://www.slideshare.net/weierophinney/architecting-your-models >> > >> > If a project doesn't have the resources to model their data like that, or >> > they need to leverage the Doctrine ecosystem to get a project done in time. >> > But in the most ideal world (where resources are not an issue), I too >> > think that this presentation shows how things should be done. >> > >> > That said, I think the quickstart should show both options, but focus on >> > the >> > Data Mapper, Service Layer stuff. >> >> I agree that the data mapper is a good way to do Models etc but I >> think the basic mapper shown in the quickstart does lead people into >> trouble. If a newcomer follows the quickstart they soon find out that >> modeling relations is very hard and they need an ORM...If we had >> Doctrine 2 integration we can then show the data mapper pattern at its >> best IMO. >> >> I have had this concern with the quickstart for a while :) > > I think we can show the current data mapper still, but then have a note > detailing ORMs and when you need to start using one (vs. a simple > hand-written data mapper). Yeah I think thats all thats needed, the only reason I raised it was that I have been asked a couple of times about the quickstart :) > >> Also will we be deprecating Zend_Db as if we have tight Doctrine >> integration is there any reason to keep Zend_Db? > > There are plenty of reasons to keep Zend_Db. Not everyone will be using > Doctrine, and for many one-off types of applications (single tables, or > multiple tables with no relations, etc.), having Zend_Db around will > continue to be essential. Additionally, one aspect I'd like to explore > with the Doctrine folks is potentially allowing Zend_Db adapters as > Doctrine RDBMS adapters; this would provide some very interesting > integration points. Sounds interesting I look forward to seeing this initiative develop further, I would be happy to help in any way I can :) Once we have the integration especially with doctrine 2 would there be any further plans to look at things like dependency injection, criteria objects and repositories or any other DDD tools? To me having a full suite of tools like this would be a great long term goal? > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- http://www.thepopeisdead.com
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- keith Pope wrote (on Friday, 30 October 2009, 04:02 PM +): > 2009/10/30 Ralph Schindler : > > > Time to go back to using Doctrine then :( bye bye nice models. > > > > > > Do you think it would be a good idea to update the Quickstart guide > > > now to not use the Data Mapper pattern and use doctrine instead? > > > > I would strongly disagree with that move. I think ZF has always offered 2 > > solid solutions to modeling: use our Data classes (Table Row, etc) to build > > out a proper model, OR use a 3rd Party ORM framework- like Doctrine. > > > > At ZendCon, i've heard more than one person say "This is the way modeling > > should be done" after seeing matthew's talk on > > > > http://www.slideshare.net/weierophinney/architecting-your-models > > > > If a project doesn't have the resources to model their data like that, or > > they need to leverage the Doctrine ecosystem to get a project done in time. > > But in the most ideal world (where resources are not an issue), I too > > think that this presentation shows how things should be done. > > > > That said, I think the quickstart should show both options, but focus on the > > Data Mapper, Service Layer stuff. > > I agree that the data mapper is a good way to do Models etc but I > think the basic mapper shown in the quickstart does lead people into > trouble. If a newcomer follows the quickstart they soon find out that > modeling relations is very hard and they need an ORM...If we had > Doctrine 2 integration we can then show the data mapper pattern at its > best IMO. > > I have had this concern with the quickstart for a while :) I think we can show the current data mapper still, but then have a note detailing ORMs and when you need to start using one (vs. a simple hand-written data mapper). > Also will we be deprecating Zend_Db as if we have tight Doctrine > integration is there any reason to keep Zend_Db? There are plenty of reasons to keep Zend_Db. Not everyone will be using Doctrine, and for many one-off types of applications (single tables, or multiple tables with no relations, etc.), having Zend_Db around will continue to be essential. Additionally, one aspect I'd like to explore with the Doctrine folks is potentially allowing Zend_Db adapters as Doctrine RDBMS adapters; this would provide some very interesting integration points. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hi Keith, I agree that the data mapper is a good way to do Models etc but I think the basic mapper shown in the quickstart does lead people into trouble. If a newcomer follows the quickstart they soon find out that modeling relations is very hard and they need an ORM...If we had Doctrine 2 integration we can then show the data mapper pattern at its best IMO. I have had this concern with the quickstart for a while :) You might be on a slippery slope here. I don't think Zend Framework should dictate how people design their applications. Sure you can encourage the use of good patterns, etc, but the choice is ultimately the user's, and if the user is not capable of making those decisions based on what they know, they might not be the right person for the right job, to be frank... I think one of ZF's unique selling points is that you can use a fraction of the framework or stack all kinds of parts on each other, but (almost) never being forced to use large code bases that you don't really need. Good design doesn't dictate implementation, imo. Also will we be deprecating Zend_Db as if we have tight Doctrine integration is there any reason to keep Zend_Db? Please keep Zend_Db! I've never used it, but making Zend Framework so much dependent on another framework is never a good thing.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/30 Ralph Schindler : > >> >> Time to go back to using Doctrine then :( bye bye nice models. >> >> Do you think it would be a good idea to update the Quickstart guide >> now to not use the Data Mapper pattern and use doctrine instead? >> > > I would strongly disagree with that move. I think ZF has always offered 2 > solid solutions to modeling: use our Data classes (Table Row, etc) to build > out a proper model, OR use a 3rd Party ORM framework- like Doctrine. > > At ZendCon, i've heard more than one person say "This is the way modeling > should be done" after seeing matthew's talk on > > http://www.slideshare.net/weierophinney/architecting-your-models > > If a project doesn't have the resources to model their data like that, or > they need to leverage the Doctrine ecosystem to get a project done in time. > But in the most ideal world (where resources are not an issue), I too > think that this presentation shows how things should be done. > > That said, I think the quickstart should show both options, but focus on the > Data Mapper, Service Layer stuff. I agree that the data mapper is a good way to do Models etc but I think the basic mapper shown in the quickstart does lead people into trouble. If a newcomer follows the quickstart they soon find out that modeling relations is very hard and they need an ORM...If we had Doctrine 2 integration we can then show the data mapper pattern at its best IMO. I have had this concern with the quickstart for a while :) Also will we be deprecating Zend_Db as if we have tight Doctrine integration is there any reason to keep Zend_Db? > > -ralph > -- http://www.thepopeisdead.com
Re: [fw-general] Undefined variable in Zend_Db_Select
I didn´t up to now: ZF-8190.
I always try to post in the lists first, just to be sure that I´m not doing
anything wrong :)
Thanks for you help.
On Fri, Oct 30, 2009 at 10:33 AM, till wrote:
> Hey Luiz,
>
> of course this is a bug, did you report it too? :-) [hint, hint]
>
> But before you do, please double-check the bug is still in 1.9.5, and
> if it is, please report it ASAP.
>
> Cheers,
> Till
>
> On Fri, Oct 30, 2009 at 11:17 AM, Luiz Vitor wrote:
> > The changes in Zend_Db_Select in 1.9.4 release started to raise an
> undefined
> > variable notice:
> >
> > ( ! ) Notice: Undefined variable: lastFromCorrelationName in
> > /data/html/vilagenet.com.br/library/Zend/Db/Select.php on line 828
> >
> > To reproduce:
> >
> > $adapter = Zend_Db_Table::getDefaultAdapter();
> > $select = $adapter->select()
> > ->from('sometable', 'id');
> >
> > $select2 = $adapter->select()
> > ->from(null, 'COUNT(*) FROM (' . $select->__toString() . ') AS
> count');
> >
> > $result = $adapter->fetchCol($select2);
> >
> > The variable $lastFromCorrelationName is declared in Zend_Db_Select on
> line
> > 798, inside an `if` statement, but is used outside it, on line 828.
> >
> > Moving the declaration to just outside the `if` (line 789) corrects the
> > problem, and all unit tests still pass.
> >
> > This is a bug or this is the intended behaviour, and I´m using the
> component
> > in a subverted way?
> >
> > Thanks in advance.
> >
> >
>
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Time to go back to using Doctrine then :( bye bye nice models. Do you think it would be a good idea to update the Quickstart guide now to not use the Data Mapper pattern and use doctrine instead? I would strongly disagree with that move. I think ZF has always offered 2 solid solutions to modeling: use our Data classes (Table Row, etc) to build out a proper model, OR use a 3rd Party ORM framework- like Doctrine. At ZendCon, i've heard more than one person say "This is the way modeling should be done" after seeing matthew's talk on http://www.slideshare.net/weierophinney/architecting-your-models If a project doesn't have the resources to model their data like that, or they need to leverage the Doctrine ecosystem to get a project done in time. But in the most ideal world (where resources are not an issue), I too think that this presentation shows how things should be done. That said, I think the quickstart should show both options, but focus on the Data Mapper, Service Layer stuff. -ralph
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I'd be very interested to have a look at your resource as I am just prototyping now for quite a large system now so would be great to have a look at what you have done. Thanks On 30 Oct 2009, at 12:03, "A.J. Brown" wrote: I use Zend Framework and Doctrine bundled together quiet frequently. If I can be of any assistance in this new direction, I'm most certainly interested in helping. In the short term, I have some code to boot Doctrine is a Zend_Application_Resource with configuration, if anyone is interested. On Fri, Oct 30, 2009 at 7:07 AM, Matthew Weier O'Phinney wrote: -- Georgy Turevich wrote (on Friday, 30 October 2009, 11:31 AM +0300): I have not understood. The component will be developed by other people? Or it is discontinue for ever? Discontinued. All development was being done basically by Benjamin himself, and my team is simply too small for me to provide him much additional support without having it affect other projects. We have considered in the past writing an ORM, and the conclusion has always been that we do not have either enough expertise or resources on our team to undertake it. I was willing to let it be a community effort, but it would have taken a dedicated team of volunteers (a) to make it happen in a reasonable time frame, and (b) to provide ongoing support for it. Benjamin got to a point where he realized he'd finished about 50% of functionality, and likely had another 4-6 months before it was releasable. At that point, we'd be gearing up for ZF 2.0, which would mean he'd need to start rewriting to make use of PHP 5.3 features. It was simply a very daunting task, and one he wasn't getting much help with. Additionally, there's the fact that Doctrine is becoming a key part of the greater PHP ecosystem. Agavi and Symfony ship with it. I've seen tutorials for using it with CodeIgniter, Cake (and the new offshoot, Lithium), and of course ZF. Considering that many developers will be using it in other projects, it makes for a natural migration point -- migrate your models from one framework to another in order to make use of a different MVC or components. It simply makes sense *not* to reinvent the wheel here, and instead spend some time doing formal integration with Doctrine in order to leverage its community of developers. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ -- A.J. Brown web | http://ajbrown.org phone | (937) 660-3969
Re: [fw-general] Undefined variable in Zend_Db_Select
Hey Luiz,
of course this is a bug, did you report it too? :-) [hint, hint]
But before you do, please double-check the bug is still in 1.9.5, and
if it is, please report it ASAP.
Cheers,
Till
On Fri, Oct 30, 2009 at 11:17 AM, Luiz Vitor wrote:
> The changes in Zend_Db_Select in 1.9.4 release started to raise an undefined
> variable notice:
>
> ( ! ) Notice: Undefined variable: lastFromCorrelationName in
> /data/html/vilagenet.com.br/library/Zend/Db/Select.php on line 828
>
> To reproduce:
>
> $adapter = Zend_Db_Table::getDefaultAdapter();
> $select = $adapter->select()
> ->from('sometable', 'id');
>
> $select2 = $adapter->select()
> ->from(null, 'COUNT(*) FROM (' . $select->__toString() . ') AS count');
>
> $result = $adapter->fetchCol($select2);
>
> The variable $lastFromCorrelationName is declared in Zend_Db_Select on line
> 798, inside an `if` statement, but is used outside it, on line 828.
>
> Moving the declaration to just outside the `if` (line 789) corrects the
> problem, and all unit tests still pass.
>
> This is a bug or this is the intended behaviour, and I´m using the component
> in a subverted way?
>
> Thanks in advance.
>
>
Re: [fw-general] Multiselect selected values
I missed out some code in my controller
Now it is working with this code
Form
$groups = new Zend_Form_Element_Multiselect('group');
$groups ->setLabel('Groups:')
->setDecorators($this->elementDecorators)
->setRegisterInArrayValidator(false)
->setAttrib('multiple','multiple')
->setMultiOptions($aGroups);
$this->addElement($groups);
Controller
$productForm = $oFrmProduct->getEditProductForm($aGroups, $groupsCnt,
$buttonMessage);
$productForm->group->setValue($sGroup);
Thanks for all
A.J. Brown-3 wrote:
>
> Have you tried:
>
> ->setDefault( $sGroup )
>
> ?
>
> On Fri, Oct 30, 2009 at 7:28 AM, ajitk15 wrote:
>>
>> Hi
>>
>> this using the Zend_Form_Element_Multiselect still i the same issue
>> can any one help me out in this asap
>>
>>
>> $groups = new Zend_Form_Element_Multiselect('group');
>>
>> $groups ->setLabel('Groups:')
>>
>> ->setDecorators($this->elementDecorators)
>>
>> ->setRegisterInArrayValidator(false)
>>
>> ->setAttrib('multiple','multiple')
>> ->setValue($sGroup)
>> ->addMultiOptions($aGroups);
>>
>> $this->addElement($groups);
>>
>>
>>
>>
>>
>> Hector Virgen wrote:
>>>
>>> If you're using a regular select, the value you pass to setValue should
>>> be
>>> a
>>> single value (not an array).
>>>
>>> If you're using MultiSelect, then you need to pass in an array of
>>> values.
>>>
>>> --
>>> Hector
>>>
>>>
>>> On Tue, Oct 27, 2009 at 8:41 AM, ajitk15 wrote:
>>>
even i tried with Zend_Form_Element_Multiselect also
still the same issue.
drm-4 wrote:
>
> ajitk15 wrote:
>> $groups = new Zend_Form_Element_Select('group');
>>
>> $groups ->setLabel('Groups:')
>>
->setAttrib('multiple','multiple')
>>
>
> Hi, you should use Zend_Form_Element_Multiselect for this.
>
>
--
View this message in context:
http://www.nabble.com/Multiselect-selected-values-tp22125736p26079939.html
Sent from the Zend Framework mailing list archive at Nabble.com.
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Multiselect-selected-values-tp22125736p26128468.html
>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> A.J. Brown
> web | http://ajbrown.org
> phone | (937) 660-3969
>
>
--
View this message in context:
http://old.nabble.com/Multiselect-selected-values-tp22125736p26129171.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Hello, Sorry about that, but I was a little bit skeptical about Zend_Entity in the first place. Mainly, as known now, because there was only one person actually doing it and therefore it seemed literally impossible to complete it in a reasonable amount of time and maintain a good code quality in the future. That's why I chose Doctrine a while back. I had a few talks about the fact that zf tries to have too much components in it (that's another topic) and always believed that it can replace some of them by 3rdparty ones. The fact, that Doctrine is chosen is wonderful for me - two brilliant libraries with good developers teams on both sides also. I have been using it with zf for quite a long time and tried a lot of different components with it (Models, Forms, Services, Paginator, Auth+Acl, etc.) so I'm up to contribute to this proposal when it becomes available. -- Juozas Kaziukėnas (juo...@juokaz.com) Aš internete - JuoKaz (http://www.juokaz.com) On Fri, Oct 30, 2009 at 11:07 AM, Matthew Weier O'Phinney wrote: > -- Georgy Turevich wrote > (on Friday, 30 October 2009, 11:31 AM +0300): > > I have not understood. The component will be developed by other people? > Or it > > is discontinue for ever? > > Discontinued. > > All development was being done basically by Benjamin himself, and my > team is simply too small for me to provide him much additional support > without having it affect other projects. We have considered in the past > writing an ORM, and the conclusion has always been that we do not have > either enough expertise or resources on our team to undertake it. I was > willing to let it be a community effort, but it would have taken a > dedicated team of volunteers (a) to make it happen in a reasonable time > frame, and (b) to provide ongoing support for it. > > Benjamin got to a point where he realized he'd finished about 50% of > functionality, and likely had another 4-6 months before it was > releasable. At that point, we'd be gearing up for ZF 2.0, which would > mean he'd need to start rewriting to make use of PHP 5.3 features. It > was simply a very daunting task, and one he wasn't getting much help > with. > > Additionally, there's the fact that Doctrine is becoming a key part of > the greater PHP ecosystem. Agavi and Symfony ship with it. I've seen > tutorials for using it with CodeIgniter, Cake (and the new offshoot, > Lithium), and of course ZF. Considering that many developers will be > using it in other projects, it makes for a natural migration point -- > migrate your models from one framework to another in order to make use > of a different MVC or components. It simply makes sense *not* to > reinvent the wheel here, and instead spend some time doing formal > integration with Doctrine in order to leverage its community of > developers. > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ >
Re: [fw-general] Multiselect selected values
Have you tried:
->setDefault( $sGroup )
?
On Fri, Oct 30, 2009 at 7:28 AM, ajitk15 wrote:
>
> Hi
>
> this using the Zend_Form_Element_Multiselect still i the same issue
> can any one help me out in this asap
>
>
> $groups = new Zend_Form_Element_Multiselect('group');
>
> $groups ->setLabel('Groups:')
>
> ->setDecorators($this->elementDecorators)
> ->setRegisterInArrayValidator(false)
> ->setAttrib('multiple','multiple')
> ->setValue($sGroup)
> ->addMultiOptions($aGroups);
>
> $this->addElement($groups);
>
>
>
>
>
> Hector Virgen wrote:
>>
>> If you're using a regular select, the value you pass to setValue should be
>> a
>> single value (not an array).
>>
>> If you're using MultiSelect, then you need to pass in an array of values.
>>
>> --
>> Hector
>>
>>
>> On Tue, Oct 27, 2009 at 8:41 AM, ajitk15 wrote:
>>
>>>
>>> even i tried with Zend_Form_Element_Multiselect also
>>> still the same issue.
>>>
>>>
>>>
>>> drm-4 wrote:
>>> >
>>> > ajitk15 wrote:
>>> >> $groups = new Zend_Form_Element_Select('group');
>>> >>
>>> >> $groups ->setLabel('Groups:')
>>> >>
>>> ->setAttrib('multiple','multiple')
>>> >>
>>> >
>>> > Hi, you should use Zend_Form_Element_Multiselect for this.
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Multiselect-selected-values-tp22125736p26079939.html
>>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/Multiselect-selected-values-tp22125736p26128468.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
>
--
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I use Zend Framework and Doctrine bundled together quiet frequently. If I can be of any assistance in this new direction, I'm most certainly interested in helping. In the short term, I have some code to boot Doctrine is a Zend_Application_Resource with configuration, if anyone is interested. On Fri, Oct 30, 2009 at 7:07 AM, Matthew Weier O'Phinney wrote: > -- Georgy Turevich wrote > (on Friday, 30 October 2009, 11:31 AM +0300): >> I have not understood. The component will be developed by other people? Or it >> is discontinue for ever? > > Discontinued. > > All development was being done basically by Benjamin himself, and my > team is simply too small for me to provide him much additional support > without having it affect other projects. We have considered in the past > writing an ORM, and the conclusion has always been that we do not have > either enough expertise or resources on our team to undertake it. I was > willing to let it be a community effort, but it would have taken a > dedicated team of volunteers (a) to make it happen in a reasonable time > frame, and (b) to provide ongoing support for it. > > Benjamin got to a point where he realized he'd finished about 50% of > functionality, and likely had another 4-6 months before it was > releasable. At that point, we'd be gearing up for ZF 2.0, which would > mean he'd need to start rewriting to make use of PHP 5.3 features. It > was simply a very daunting task, and one he wasn't getting much help > with. > > Additionally, there's the fact that Doctrine is becoming a key part of > the greater PHP ecosystem. Agavi and Symfony ship with it. I've seen > tutorials for using it with CodeIgniter, Cake (and the new offshoot, > Lithium), and of course ZF. Considering that many developers will be > using it in other projects, it makes for a natural migration point -- > migrate your models from one framework to another in order to make use > of a different MVC or components. It simply makes sense *not* to > reinvent the wheel here, and instead spend some time doing formal > integration with Doctrine in order to leverage its community of > developers. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- A.J. Brown web | http://ajbrown.org phone | (937) 660-3969
Re: [fw-general] Multiselect selected values
Hi
this using the Zend_Form_Element_Multiselect still i the same issue
can any one help me out in this asap
$groups = new Zend_Form_Element_Multiselect('group');
$groups ->setLabel('Groups:')
->setDecorators($this->elementDecorators)
->setRegisterInArrayValidator(false)
->setAttrib('multiple','multiple')
->setValue($sGroup)
->addMultiOptions($aGroups);
$this->addElement($groups);
Hector Virgen wrote:
>
> If you're using a regular select, the value you pass to setValue should be
> a
> single value (not an array).
>
> If you're using MultiSelect, then you need to pass in an array of values.
>
> --
> Hector
>
>
> On Tue, Oct 27, 2009 at 8:41 AM, ajitk15 wrote:
>
>>
>> even i tried with Zend_Form_Element_Multiselect also
>> still the same issue.
>>
>>
>>
>> drm-4 wrote:
>> >
>> > ajitk15 wrote:
>> >> $groups = new Zend_Form_Element_Select('group');
>> >>
>> >> $groups ->setLabel('Groups:')
>> >>
>> ->setAttrib('multiple','multiple')
>> >>
>> >
>> > Hi, you should use Zend_Form_Element_Multiselect for this.
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Multiselect-selected-values-tp22125736p26079939.html
>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/Multiselect-selected-values-tp22125736p26128468.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
-- Georgy Turevich wrote (on Friday, 30 October 2009, 11:31 AM +0300): > I have not understood. The component will be developed by other people? Or it > is discontinue for ever? Discontinued. All development was being done basically by Benjamin himself, and my team is simply too small for me to provide him much additional support without having it affect other projects. We have considered in the past writing an ORM, and the conclusion has always been that we do not have either enough expertise or resources on our team to undertake it. I was willing to let it be a community effort, but it would have taken a dedicated team of volunteers (a) to make it happen in a reasonable time frame, and (b) to provide ongoing support for it. Benjamin got to a point where he realized he'd finished about 50% of functionality, and likely had another 4-6 months before it was releasable. At that point, we'd be gearing up for ZF 2.0, which would mean he'd need to start rewriting to make use of PHP 5.3 features. It was simply a very daunting task, and one he wasn't getting much help with. Additionally, there's the fact that Doctrine is becoming a key part of the greater PHP ecosystem. Agavi and Symfony ship with it. I've seen tutorials for using it with CodeIgniter, Cake (and the new offshoot, Lithium), and of course ZF. Considering that many developers will be using it in other projects, it makes for a natural migration point -- migrate your models from one framework to another in order to make use of a different MVC or components. It simply makes sense *not* to reinvent the wheel here, and instead spend some time doing formal integration with Doctrine in order to leverage its community of developers. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] ZF Custom Router
Hi, its work exellent! Tanks prodigitalson ! My mistake was in routes order. -- View this message in context: http://old.nabble.com/ZF-Custom-Router-tp26052315p26128162.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Undefined variable in Zend_Db_Select
The changes in Zend_Db_Select in 1.9.4 release started to raise an undefined
variable notice:
( ! ) Notice: Undefined variable: lastFromCorrelationName in /data/html/
vilagenet.com.br/library/Zend/Db/Select.php on line 828
To reproduce:
$adapter = Zend_Db_Table::getDefaultAdapter();
$select = $adapter->select()
->from('sometable', 'id');
$select2 = $adapter->select()
->from(null, 'COUNT(*) FROM (' . $select->__toString() . ') AS count');
$result = $adapter->fetchCol($select2);
The variable $lastFromCorrelationName is declared in Zend_Db_Select on line
798, inside an `if` statement, but is used outside it, on line 828.
Moving the declaration to just outside the `if` (line 789) corrects the
problem, and all unit tests still pass.
This is a bug or this is the intended behaviour, and I´m using the component
in a subverted way?
Thanks in advance.
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
Benjamin Eberlei wrote: I just want to inform everyone that I will discontinue development on Zend Entity and in return invest time to integrate Doctrine with Zend Framework on a large scale. Excellent decision! Though I know writing a good ORM is a very fun job and I am sure you will miss it, I am very happy with this, because Yet Another ORM isn't really what we needed, imho :-) I would like to help, but I'm not sure how. drm / Gerard
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
I have not understood. The component will be developed by other people? Or it is discontinue for ever?
Re: [fw-general] Zend_Locale
Why locale is not on this page
http://framework.zend.com/manual/en/zend.application.available-resources.html?
Can you give example setting it from config?
Regards,
Saša Stamenković
On Thu, Oct 29, 2009 at 10:59 PM, Ed Lazor
wrote:
> >> I'm trying to clean up my bootstrap. Is there a way to move these
> >> lines to application.ini?
> >>
> >> setlocale(LC_ALL, 'en_US.utf8');
> >> Zend_Locale::setDefault('en');
> >>
> >> I read through the manual and it looks like this is required in the
> >> bootstrap, but I'd like to double check.
> >>
> >
> > Take a look at /Zend/Application/Resource/Locale.php
> >
> > resources.locale.default…
>
>
> Thanks =)
>
> Any ideas on this one? I have this in my bootstrap and I'm trying to
> move it to application.ini
>
> setlocale(LC_ALL, 'en_US.utf8');
>
>
> I put this line in application.ini, but no luck:
>
> phpSettings.intl.default_locale = "en_US.utf8"
>
>
> In my tests to make sure that it's working properly, I've used "nl_NL"
> and I'm echoing this on a test page:
>
> echo strftime("%A %e %B %Y", mktime(0, 0, 0, 12, 22, 1978));
>
> If it's working correctly and the settings are "nl_NL", the output would
> end up:
>
> vrijdag 22 december 1978
>
> But instead, it always shows up in english until I actually use the
> setLocale command.
>
> Any ideas?
>
> -Ed
>
Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine integration
2009/10/29 Benjamin Eberlei : > Hello Keith, > > you should take a look at Doctrine 2. As Zend Entity it implements the JPA > specification and is a true data mapper with models decoupled from Database > completly. Looking now, I didnt think it was nearing release yet last time I looked it seemed far off, time obviously passes too quickly hehe Wish I didnt have to upgrade to PHP 5.3 to use it though, working on legacy systems means its a lot of work! But too be fair it needs to be done anyway :) When are the integration discussions happening? Thanks for your work on Zend_Entity its been informative watching it develop anyway :) > > greetings, > Benjamin > > On Thursday 29 October 2009 09:19:50 pm keith Pope wrote: >> 29 Matthew Weier O'Phinney : >> > -- Antonio José García Lagar wrote >> > >> > (on Thursday, 29 October 2009, 08:17 PM +0100): >> >> 2009/10/29 Matthew Weier O'Phinney >> >> >> >> >> >> Ideally, we'll have both Doctrine 1.x and 2.x integration, for this >> >> very reason - though likely as separate implementations (Zend_Doctrine, >> >> Zend_Doctrine2). There are some commonalities between them that we can >> >> leverage immediately (application resources, in particular), and others >> >> that will require more collaboration between the two projects (e.g., >> >> shared cache objects and loggers, etc.). >> >> I must say its a shame that ZE is going, I thought it was too bigger a >> project for one person, not fair asking for that much commitment from >> anyone. >> >> Time to go back to using Doctrine then :( bye bye nice models. >> >> Do you think it would be a good idea to update the Quickstart guide >> now to not use the Data Mapper pattern and use doctrine instead? >> >> >> Do you think this will be available for the 1.10 release? >> >> >> >> You should update the roadmap at >> >> http://framework.zend.com/roadmap/1.10.0 >> >> >> >> I hope to see an early proposal to start to help. >> > >> > We're in the very early stages of gathering requirements; I honestly >> > don't see it being ready for 1.10. >> > >> > -- >> > Matthew Weier O'Phinney >> > Project Lead | matt...@zend.com >> > Zend Framework | http://framework.zend.com/ > > > -- > Benjamin Eberlei > http://www.beberlei.de > -- http://www.thepopeisdead.com
Re: [fw-general] css class to option tags
I'll try with plugin namespces, thanks. About having option (setClassName()),
I don't see how can you use it, because rendering is initialized and
triggered by Zend_Form_Element_Select, maybe you can subclass it, but this
leads to complications. Or I'm missing sth?
Regards,
Saša Stamenković
On Thu, Oct 29, 2009 at 4:16 PM, drm wrote:
> Саша Стаменковић wrote:
>
>> class Umpirsky_View_Helper_FormSelectCustom extends
>> Zend_View_Helper_FormSelect {
>>
> Hi Saša,
>
> Good solution, which I would have suggested if same classes for all the
> options wouldn't suffice.
>
> Little suggestion: name your class Umpirsky_View_Helper_FormSelect and add
> Umpirsky_View_Helper_ as a plugin namespace to the view helper's plugin
> loader, and remove the formSelectCustom() method from the class. This way
> you don't have to explicitly refer to your "formSelectCustom" view helper.
> Make the setting of the classname an option (setClassName()) so _build() can
> delegate to parent::_build() if the option is not set. This way you can
> generically implement other class names for different types of selects in
> stead of needing more view helpers.
>
>
