Since its creation, more than 7 years ago, CakePHP has grown with a life of its own. Its main goal has always been to empower developers with tools that are both easy to learn and use, leverage great libraries requiring low documentation and low dependencies too. We've had several big releases along these years and an ever growing community. Being one of the most popular frameworks out there and probably the first one (!) we have also gotten a lot of criticism from the developer community in general. We have, though, accepted it and learnt from our mistakes to keep building the best PHP framework there is.
CakePHP is known for having a very slow pace of adopting new stuff and it has served very well to its community. Back when we were doing version 2.0 we decided to hold on version 5.2 of PHP for multiple reasons and despite it didn't let us innovate as much as we wished to, it was an excellent choice given the general environment regarding hosting solutions and general adoption of PHP 5.3. A look back into the past reminded us that we were big innovators in PHP, bringing features to developers that few dreamt possible to do in this language. Now, it's time to look ahead in future and decide on staying in our comfort zone or take back our leading position as innovators.
So it is with great excitement that we announce we are putting our our efforts in bringing you the next major release of CakePHP. Version 3.0 will leverage the new features in PHP 5.4 and will include an important change in our models and database system. CakePHP 3.0 will not be ready less than 6 or 8 months and we reckon that, given the rise of cheap cloud hosting solutions and upcoming release of new operating system versions, there is no better time to jump on the most current stable version of PHP.
As you may already know, PHP 5.4 offers awesome features that would introduce useful new concepts and interesting solutions to old problems. Closure binding, traits, multibyte support are tools we see of great usefulness for properly implemented advanced framework features we've had in mind for a long time. Also new syntax sugar added to the language will make it more pleasant to write both small and complex applications with the framework and a always welcomed free performance increase.
We have a young but already well defined road map for what we want to accomplish in next release and you are invited to contribute and suggest what's next:
- Drop support for 5.2.x and support 5.4+ only - Add proper namespaces for all classes. This will make it easier to reuse classes outside CakePHP and to use external libraries and finally no chances of collisions between your app classes and core ones. - Use traits were possible and makes sense - Improve bootstrapping process to allow more developer control and better performance - Model layer rewrite: - Models to return objects from queries - Datamapper-like paradigm - Richer query API - Support for any database type - Support for more database drivers both PDO and native - Improve Router: - Make it faster - Remove named parameters - Add support for named routes - Smarter router prefixes - Shorter url syntax
As you may imagine most of the time will be spent or rewriting the model layer, but it will also be one of the most powerful features CakePHP 3.0 will have. It's new architecture based on PHP 5.4 capabilities will offer an easier and more powerful set of tools to build web applications in no time.
If you are already as excited as we are this all this new stuff coming, you definitely should meet us on next CakeFest <http://cakefest.org/> we'll be talking about the future of CakePHP and hacking our way through to bring you a dev release as soon as possible. Wouldn't it be lovely to attend to awesome talks, workshops and also be part of the group deciding initial architecture for next major version of the framework? Make sure you book your tickets before we run out of them!
We're always looking for different people having a vision on software development, are you interested in helping out? There is no better time to start sending patches and become one of the core team!
On Fri, Jul 6, 2012 at 9:47 AM, Ilie <ilie.pan...@gmail.com> wrote:
> Why the removal of named parameters in the Router? They are quite useful to
> me and the Paginator uses them to keep track of page.
> What would be used instead?
Guess named routes and smarter prefixes in combo will probably work the same
Just a speculation
T
-- =============================================================
PHP for E-Biz: http://sanisoft.com =============================================================
On Friday, July 6, 2012 4:36:03 AM UTC+2, José Lorenzo wrote:
> - Model layer rewrite:
> - Models to return objects from queries
> - Datamapper-like paradigm
> - Richer query API
> - Support for any database type
> - Support for more database drivers both PDO and native
> The new model layer will be an exciting feature. But it also looks like it
is going to be very different from CakePHP 2.
Is there going to be an update path for CakePHP 2 apps to CakePHP 3?
First of all, big kudos to the developers of CakePHP. It is an excellent, well thought out and well engineered framework. It does indeed look very traditional and conservative and that is a Good Thing(tm). That's why I see with horror the mention of moving to the objects returned by models from queries. Would you leave them alone, please? We work in a data-centric environment here and there is nothing better than associative arrays to do that. Please, leave data alone and better improve the handling of data arrays where the effects of various calls are not obvious. That will be a much better deal. I do not expect that many people selected CakePHP in the hope that it would move to object-oriented data. There are other frameworks for that.
On Friday, July 6, 2012 4:36:03 AM UTC+2, José Lorenzo wrote:
> Since its creation, more than 7 years ago, CakePHP has grown with a life > of its own. Its main goal has always been to empower developers with tools > that are both easy to learn and use, leverage great libraries requiring low > documentation and low dependencies too. We've had several big releases > along these years and an ever growing community. Being one of the most > popular frameworks out there and probably the first one (!) we have also > gotten a lot of criticism from the developer community in general. We have, > though, accepted it and learnt from our mistakes to keep building the best > PHP framework there is.
> CakePHP is known for having a very slow pace of adopting new stuff and it > has served very well to its community. Back when we were doing version 2.0 > we decided to hold on version 5.2 of PHP for multiple reasons and despite > it didn't let us innovate as much as we wished to, it was an excellent > choice given the general environment regarding hosting solutions and > general adoption of PHP 5.3. A look back into the past reminded us that we > were big innovators in PHP, bringing features to developers that few dreamt > possible to do in this language. Now, it's time to look ahead in future and > decide on staying in our comfort zone or take back our leading position as > innovators.
> So it is with great excitement that we announce we are putting our our > efforts in bringing you the next major release of CakePHP. Version 3.0 will > leverage the new features in PHP 5.4 and will include an important change > in our models and database system. CakePHP 3.0 will not be ready less than > 6 or 8 months and we reckon that, given the rise of cheap cloud hosting > solutions and upcoming release of new operating system versions, there is > no better time to jump on the most current stable version of PHP.
> As you may already know, PHP 5.4 offers awesome features that would > introduce useful new concepts and interesting solutions to old problems. > Closure binding, traits, multibyte support are tools we see of great > usefulness for properly implemented advanced framework features we've had > in mind for a long time. Also new syntax sugar added to the language will > make it more pleasant to write both small and complex applications with the > framework and a always welcomed free performance increase.
> We have a young but already well defined road map for what we want to > accomplish in next release and you are invited to contribute and suggest > what's next:
> - Drop support for 5.2.x and support 5.4+ only
> - Add proper namespaces for all classes. This will make it easier to > reuse classes outside CakePHP and to use external libraries and finally no > chances of collisions between your app classes and core ones.
> - Use traits were possible and makes sense
> - Improve bootstrapping process to allow more developer control and > better performance
> - Model layer rewrite:
> - Models to return objects from queries
> - Datamapper-like paradigm
> - Richer query API
> - Support for any database type
> - Support for more database drivers both PDO and native
> - Improve Router:
> - Make it faster
> - Remove named parameters
> - Add support for named routes
> - Smarter router prefixes
> - Shorter url syntax
> As you may imagine most of the time will be spent or rewriting the model > layer, but it will also be one of the most powerful features CakePHP 3.0 > will have. It's new architecture based on PHP 5.4 capabilities will offer > an easier and more powerful set of tools to build web applications in no > time.
> If you are already as excited as we are this all this new stuff coming, > you definitely should meet us on next CakeFest <http://cakefest.org/> we'll > be talking about the future of CakePHP and hacking our way through to bring > you a dev release as soon as possible. Wouldn't it be lovely to attend to > awesome talks, workshops and also be part of the group deciding initial > architecture for next major version of the framework? Make sure you book > your tickets before we run out of them!
> We're always looking for different people having a vision on software > development, are you interested in helping out? There is no better time to > start sending patches and become one of the core team!
On Fri, Jul 6, 2012 at 6:33 AM, Kazik <kaz...@gmail.com> wrote:
> On Friday, July 6, 2012 4:36:03 AM UTC+2, José Lorenzo wrote:
>> - Model layer rewrite:
>> - Models to return objects from queries
>> - Datamapper-like paradigm
>> - Richer query API
>> - Support for any database type
>> - Support for more database drivers both PDO and native
>> The new model layer will be an exciting feature. But it also looks like
> it is going to be very different from CakePHP 2.
> Is there going to be an update path for CakePHP 2 apps to CakePHP 3?
> k
> --
> Our newest site for the community: CakePHP Video Tutorials
> http://tv.cakephp.org > Check out the new CakePHP Questions site http://ask.cakephp.org and help
> others with their CakePHP related questions.
> To unsubscribe from this group, send email to
> cake-php+unsubscribe@googlegroups.com For more options, visit this group
> at http://groups.google.com/group/cake-php
________________________________ Von: Andy Gale <a...@salgo.net> An: cake-php@googlegroups.com Gesendet: 15:19 Freitag, 6.Juli 2012 Betreff: Re: 3.0: a peek into CakePHP's future
On Fri, Jul 6, 2012 at 2:17 PM, Marsson C. <marss...@gmail.com> wrote:
> Does it mean Cake 3.0´s Model will return objects instead of arrays ?
-- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
To unsubscribe from this group, send email to cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
They were just a bad copy of the query string with tons of problems and performance issues. They will continue to work in read-only mode, but cake will produce query string variables instead.
> On Fri, Jul 6, 2012 at 6:33 AM, Kazik <kaz...@gmail.com> wrote:
>> On Friday, July 6, 2012 4:36:03 AM UTC+2, José Lorenzo wrote:
>>> - Model layer rewrite:
>>> - Models to return objects from queries
>>> - Datamapper-like paradigm
>>> - Richer query API
>>> - Support for any database type
>>> - Support for more database drivers both PDO and native
>>> The new model layer will be an exciting feature. But it also looks like >> it is going to be very different from CakePHP 2.
>> Is there going to be an update path for CakePHP 2 apps to CakePHP 3?
>> k
>> -- >> Our newest site for the community: CakePHP Video Tutorials >> http://tv.cakephp.org >> Check out the new CakePHP Questions site http://ask.cakephp.org and help >> others with their CakePHP related questions.
>> To unsubscribe from this group, send email to
>> cake-php+unsubscribe@googlegroups.com For more options, visit this group >> at http://groups.google.com/group/cake-php
On Friday, July 6, 2012 6:12:47 AM UTC-4:30, tigr wrote:
> Hi!
> First of all, big kudos to the developers of CakePHP. It is an excellent, > well thought out and well engineered framework. It does indeed look very > traditional and conservative and that is a Good Thing(tm). That's why I see > with horror the mention of moving to the objects returned by models from > queries. Would you leave them alone, please? We work in a data-centric > environment here and there is nothing better than associative arrays to do > that. Please, leave data alone and better improve the handling of data > arrays where the effects of various calls are not obvious. That will be a > much better deal. I do not expect that many people selected CakePHP in the > hope that it would move to object-oriented data. There are other frameworks > for that.
You will be able to work with the table object and have arrays returned back. Models (rows) will be objects, though.
> On Friday, July 6, 2012 4:36:03 AM UTC+2, José Lorenzo wrote:
>> Since its creation, more than 7 years ago, CakePHP has grown with a life >> of its own. Its main goal has always been to empower developers with tools >> that are both easy to learn and use, leverage great libraries requiring low >> documentation and low dependencies too. We've had several big releases >> along these years and an ever growing community. Being one of the most >> popular frameworks out there and probably the first one (!) we have also >> gotten a lot of criticism from the developer community in general. We have, >> though, accepted it and learnt from our mistakes to keep building the best >> PHP framework there is.
>> CakePHP is known for having a very slow pace of adopting new stuff and it >> has served very well to its community. Back when we were doing version 2.0 >> we decided to hold on version 5.2 of PHP for multiple reasons and despite >> it didn't let us innovate as much as we wished to, it was an excellent >> choice given the general environment regarding hosting solutions and >> general adoption of PHP 5.3. A look back into the past reminded us that we >> were big innovators in PHP, bringing features to developers that few dreamt >> possible to do in this language. Now, it's time to look ahead in future and >> decide on staying in our comfort zone or take back our leading position as >> innovators.
>> So it is with great excitement that we announce we are putting our our >> efforts in bringing you the next major release of CakePHP. Version 3.0 will >> leverage the new features in PHP 5.4 and will include an important change >> in our models and database system. CakePHP 3.0 will not be ready less than >> 6 or 8 months and we reckon that, given the rise of cheap cloud hosting >> solutions and upcoming release of new operating system versions, there is >> no better time to jump on the most current stable version of PHP.
>> As you may already know, PHP 5.4 offers awesome features that would >> introduce useful new concepts and interesting solutions to old problems. >> Closure binding, traits, multibyte support are tools we see of great >> usefulness for properly implemented advanced framework features we've had >> in mind for a long time. Also new syntax sugar added to the language will >> make it more pleasant to write both small and complex applications with the >> framework and a always welcomed free performance increase.
>> We have a young but already well defined road map for what we want to >> accomplish in next release and you are invited to contribute and suggest >> what's next:
>> - Drop support for 5.2.x and support 5.4+ only
>> - Add proper namespaces for all classes. This will make it easier to >> reuse classes outside CakePHP and to use external libraries and finally no >> chances of collisions between your app classes and core ones.
>> - Use traits were possible and makes sense
>> - Improve bootstrapping process to allow more developer control and >> better performance
>> - Model layer rewrite:
>> - Models to return objects from queries
>> - Datamapper-like paradigm
>> - Richer query API
>> - Support for any database type
>> - Support for more database drivers both PDO and native
>> - Improve Router:
>> - Make it faster
>> - Remove named parameters
>> - Add support for named routes
>> - Smarter router prefixes
>> - Shorter url syntax
>> As you may imagine most of the time will be spent or rewriting the model >> layer, but it will also be one of the most powerful features CakePHP 3.0 >> will have. It's new architecture based on PHP 5.4 capabilities will offer >> an easier and more powerful set of tools to build web applications in no >> time.
>> If you are already as excited as we are this all this new stuff coming, >> you definitely should meet us on next CakeFest <http://cakefest.org/> we'll >> be talking about the future of CakePHP and hacking our way through to bring >> you a dev release as soon as possible. Wouldn't it be lovely to attend to >> awesome talks, workshops and also be part of the group deciding initial >> architecture for next major version of the framework? Make sure you book >> your tickets before we run out of them!
>> We're always looking for different people having a vision on software >> development, are you interested in helping out? There is no better time to >> start sending patches and become one of the core team!
I'm also cautious about moving to objects. I really like the way
Cake's arrays work. However, I presume that this will mean that the
model will be available in the view, which will be useful in some
cases.
I've worked with Cake since the 1.1 release, and recently I've worked a lot with Symfony, and on larger scale apps, which has helped me understand the strengths and weaknesess of both frameworks.
So, a chance to express an opinion on the future of Cake? How could I possibly resist :)
(Disclaimer: All of this is just my opinion /POV, not preaching here...)
Obviously it's important not to throw the baby out with the bath water - DRY, Convention over config, auto-magic/scaffold features, etc are some of the key features that differentiate Cake from other frameworks, and losing this for the sake of a design pattern or a ridiculous amount of abstraction shouldn't be risked.
* A clearer Dependency Injection model for core classes. I didn't think Cake had anything like this then I read a post on overriding the Request class, and I was like 'is this DI?' SF2 has a DI component that can be reused for this I think.
* Appropriate use of arrays. There's a time and a place for arrays, and, imho, data is a good use, and advanced config is not.
I love Cake's convention over config approach (vs the bloated yaml files of Symfony) but when you *do* need that config, arrays won't cut-it for more complex stuff. The support for ini files in Cake 2 is a great step forward in this, and, imho, json, xml, and ini files should be natively supported for some app config, and similar for value-object creation.
* Greater modularity - obviously the move to name spaces (and I hope PSR standards?) is linked to this.
I think partitioning the folders as per https://groups.google.com/forum/?fromgroups#!topic/cake-php/msttsVAG9tI, and making the different libraries work independently, would be ideal- why shouldn't someone be able to use the SF2 Router and the ZF Controller layer and the Cake model layer if that's what works for them? Or migrate their enterprise app over to another framework incrementally?
For example, take the model layer- Imho, the model later is one of Cake's best features, and changes should be cautious. * Standalone library - I think being able to use Cake's model layer as a stand-alone would massively increase the mind-share of Cake.
* OO changes - it's a matter of opinion, but Cake's arrays aren't really a massive issue for me. Given you can usually access arrays with object syntax, and there's various community behaviors to achieve this effect anyway, I don't think this a deal breaker.
Value Objects makes some sense, but I personally hope Cake never goes the way of $record->save, and always keeps with $model->save. Imho, putting too much DB behaviour into the row-level objects leads to a much more complex system, where it's a lot easier to implement poor SQL. If people want that approach, don't re-invent the wheel, Doctrine and Propel are mature libs and they don't need any more competitors :)
One places the models could definitely do with a revamp is the setting of validation rules.
Once I'm 4 levels deep into the array config, I wish I was making classes or objects or using a separate config format!
Okay, sorry for the rant, but I'd be interested to see how closely my views align with the community at large...
On Friday, 6 July 2012 03:36:03 UTC+1, José Lorenzo wrote:
> Since its creation, more than 7 years ago, CakePHP has grown with a life > of its own. Its main goal has always been to empower developers with tools > that are both easy to learn and use, leverage great libraries requiring low > documentation and low dependencies too. We've had several big releases > along these years and an ever growing community. Being one of the most > popular frameworks out there and probably the first one (!) we have also > gotten a lot of criticism from the developer community in general. We have, > though, accepted it and learnt from our mistakes to keep building the best > PHP framework there is.
> CakePHP is known for having a very slow pace of adopting new stuff and it > has served very well to its community. Back when we were doing version 2.0 > we decided to hold on version 5.2 of PHP for multiple reasons and despite > it didn't let us innovate as much as we wished to, it was an excellent > choice given the general environment regarding hosting solutions and > general adoption of PHP 5.3. A look back into the past reminded us that we > were big innovators in PHP, bringing features to developers that few dreamt > possible to do in this language. Now, it's time to look ahead in future and > decide on staying in our comfort zone or take back our leading position as > innovators.
> So it is with great excitement that we announce we are putting our our > efforts in bringing you the next major release of CakePHP. Version 3.0 will > leverage the new features in PHP 5.4 and will include an important change > in our models and database system. CakePHP 3.0 will not be ready less than > 6 or 8 months and we reckon that, given the rise of cheap cloud hosting > solutions and upcoming release of new operating system versions, there is > no better time to jump on the most current stable version of PHP.
> As you may already know, PHP 5.4 offers awesome features that would > introduce useful new concepts and interesting solutions to old problems. > Closure binding, traits, multibyte support are tools we see of great > usefulness for properly implemented advanced framework features we've had > in mind for a long time. Also new syntax sugar added to the language will > make it more pleasant to write both small and complex applications with the > framework and a always welcomed free performance increase.
> We have a young but already well defined road map for what we want to > accomplish in next release and you are invited to contribute and suggest > what's next:
> - Drop support for 5.2.x and support 5.4+ only
> - Add proper namespaces for all classes. This will make it easier to > reuse classes outside CakePHP and to use external libraries and finally no > chances of collisions between your app classes and core ones.
> - Use traits were possible and makes sense
> - Improve bootstrapping process to allow more developer control and > better performance
> - Model layer rewrite:
> - Models to return objects from queries
> - Datamapper-like paradigm
> - Richer query API
> - Support for any database type
> - Support for more database drivers both PDO and native
> - Improve Router:
> - Make it faster
> - Remove named parameters
> - Add support for named routes
> - Smarter router prefixes
> - Shorter url syntax
> As you may imagine most of the time will be spent or rewriting the model > layer, but it will also be one of the most powerful features CakePHP 3.0 > will have. It's new architecture based on PHP 5.4 capabilities will offer > an easier and more powerful set of tools to build web applications in no > time.
> If you are already as excited as we are this all this new stuff coming, > you definitely should meet us on next CakeFest <http://cakefest.org/> we'll > be talking about the future of CakePHP and hacking our way through to bring > you a dev release as soon as possible. Wouldn't it be lovely to attend to > awesome talks, workshops and also be part of the group deciding initial > architecture for next major version of the framework? Make sure you book > your tickets before we run out of them!
> We're always looking for different people having a vision on software > development, are you interested in helping out? There is no better time to > start sending patches and become one of the core team!
I'm excited to try out 3.0 but please, PLEASE don't make Cake into
anything like Symfony! Do. Not. Like.
I agree that model validation could use some freshening, although I
don't personally have any great ideas for doing that.
I don't understand the desire to use parts of one framework with
another, btw. Or even using the model layer on its own. I know I may
just be missing something but it seems bizarre to me.
On Fri, Jul 6, 2012 at 5:50 PM, the_woodsman <elwood.ca...@gmail.com> wrote:
> I've worked with Cake since the 1.1 release, and recently I've worked a lot
> with Symfony, and on larger scale apps, which has helped me understand the
> strengths and weaknesess of both frameworks.
> So, a chance to express an opinion on the future of Cake? How could I
> possibly resist :)
> (Disclaimer: All of this is just my opinion /POV, not preaching here...)
> Obviously it's important not to throw the baby out with the bath water -
> DRY, Convention over config, auto-magic/scaffold features, etc are some of
> the key features that differentiate Cake from other frameworks, and losing
> this for the sake of a design pattern or a ridiculous amount of abstraction
> shouldn't be risked.
> * A clearer Dependency Injection model for core classes. I didn't think
> Cake had anything like this then I read a post on overriding the Request
> class, and I was like 'is this DI?' SF2 has a DI component that can be
> reused for this I think.
> * Appropriate use of arrays. There's a time and a place for arrays, and,
> imho, data is a good use, and advanced config is not.
> I love Cake's convention over config approach (vs the bloated yaml files of
> Symfony) but when you *do* need that config, arrays won't cut-it for more
> complex stuff.
> The support for ini files in Cake 2 is a great step forward in this, and,
> imho, json, xml, and ini files should be natively supported for some app
> config, and similar for value-object creation.
> * Greater modularity - obviously the move to name spaces (and I hope PSR
> standards?) is linked to this.
> I think partitioning the folders as per
> https://groups.google.com/forum/?fromgroups#!topic/cake-php/msttsVAG9tI, and
> making the different libraries work independently, would be ideal- why
> shouldn't someone be able to use the SF2 Router and the ZF Controller layer
> and the Cake model layer if that's what works for them? Or migrate their
> enterprise app over to another framework incrementally?
> For example, take the model layer- Imho, the model later is one of Cake's
> best features, and changes should be cautious.
> * Standalone library - I think being able to use Cake's model layer as a
> stand-alone would massively increase the mind-share of Cake.
> * OO changes - it's a matter of opinion, but Cake's arrays aren't really a
> massive issue for me. Given you can usually access arrays with object
> syntax, and there's various community behaviors to achieve this effect
> anyway, I don't think this a deal breaker.
> Value Objects makes some sense, but I personally hope Cake never goes the
> way of $record->save, and always keeps with $model->save.
> Imho, putting too much DB behaviour into the row-level objects leads to a
> much more complex system, where it's a lot easier to implement poor SQL.
> If people want that approach, don't re-invent the wheel, Doctrine and
> Propel are mature libs and they don't need any more competitors :)
> One places the models could definitely do with a revamp is the setting of
> validation rules.
> Once I'm 4 levels deep into the array config, I wish I was making classes or
> objects or using a separate config format!
> Okay, sorry for the rant, but I'd be interested to see how closely my views
> align with the community at large...
> On Friday, 6 July 2012 03:36:03 UTC+1, José Lorenzo wrote:
>> Since its creation, more than 7 years ago, CakePHP has grown with a life
>> of its own. Its main goal has always been to empower developers with tools
>> that are both easy to learn and use, leverage great libraries requiring low
>> documentation and low dependencies too. We've had several big releases along
>> these years and an ever growing community. Being one of the most popular
>> frameworks out there and probably the first one (!) we have also gotten a
>> lot of criticism from the developer community in general. We have, though,
>> accepted it and learnt from our mistakes to keep building the best PHP
>> framework there is.
>> CakePHP is known for having a very slow pace of adopting new stuff and it
>> has served very well to its community. Back when we were doing version 2.0
>> we decided to hold on version 5.2 of PHP for multiple reasons and despite it
>> didn't let us innovate as much as we wished to, it was an excellent choice
>> given the general environment regarding hosting solutions and general
>> adoption of PHP 5.3. A look back into the past reminded us that we were big
>> innovators in PHP, bringing features to developers that few dreamt possible
>> to do in this language. Now, it's time to look ahead in future and decide on
>> staying in our comfort zone or take back our leading position as innovators.
>> So it is with great excitement that we announce we are putting our our
>> efforts in bringing you the next major release of CakePHP. Version 3.0 will
>> leverage the new features in PHP 5.4 and will include an important change in
>> our models and database system. CakePHP 3.0 will not be ready less than 6 or
>> 8 months and we reckon that, given the rise of cheap cloud hosting solutions
>> and upcoming release of new operating system versions, there is no better
>> time to jump on the most current stable version of PHP.
>> As you may already know, PHP 5.4 offers awesome features that would
>> introduce useful new concepts and interesting solutions to old problems.
>> Closure binding, traits, multibyte support are tools we see of great
>> usefulness for properly implemented advanced framework features we've had in
>> mind for a long time. Also new syntax sugar added to the language will make
>> it more pleasant to write both small and complex applications with the
>> framework and a always welcomed free performance increase.
>> We have a young but already well defined road map for what we want to
>> accomplish in next release and you are invited to contribute and suggest
>> what's next:
>> Drop support for 5.2.x and support 5.4+ only
>> Add proper namespaces for all classes. This will make it easier to reuse
>> classes outside CakePHP and to use external libraries and finally no chances
>> of collisions between your app classes and core ones.
>> Use traits were possible and makes sense
>> Improve bootstrapping process to allow more developer control and better
>> performance
>> Model layer rewrite:
>> Models to return objects from queries
>> Datamapper-like paradigm
>> Richer query API
>> Support for any database type
>> Support for more database drivers both PDO and native
>> Improve Router:
>> Make it faster
>> Remove named parameters
>> Add support for named routes
>> Smarter router prefixes
>> Shorter url syntax
>> As you may imagine most of the time will be spent or rewriting the model
>> layer, but it will also be one of the most powerful features CakePHP 3.0
>> will have. It's new architecture based on PHP 5.4 capabilities will offer an
>> easier and more powerful set of tools to build web applications in no time.
>> If you are already as excited as we are this all this new stuff coming,
>> you definitely should meet us on next CakeFest we'll be talking about the
>> future of CakePHP and hacking our way through to bring you a dev release as
>> soon as possible. Wouldn't it be lovely to attend to awesome talks,
>> workshops and also be part of the group deciding initial architecture for
>> next major version of the framework? Make sure you book your tickets before
>> we run out of them!
>> We're always looking for different people having a vision on software
>> development, are you interested in helping out? There is no better time to
>> start sending patches and become one of the core team!
> --
> Our newest site for the community: CakePHP Video Tutorials
> http://tv.cakephp.org > Check out the new CakePHP Questions site http://ask.cakephp.org and help
> others with their CakePHP related questions.
> To unsubscribe from this group, send email to
> cake-php+unsubscribe@googlegroups.com For more options, visit this group at
> http://groups.google.com/group/cake-php
No, that is not "nice". The strength of the CakePHP design is in being very straightforward when it comes to working with the data. I have seen other frameworks and I think that object-oriented ways are not suitable for working with data. Well, of course, you can, but would you want to, given a choice? My answer was "no" and that is why I am using Cake. I am worried that the object-oriented hype will get the best of you and we will lose a perfectly sensible data processing framework to the object-oriented glory. For practical reasons, it would be great to leave the model layer principles as they are.
On Saturday, 7 July 2012 11:35:08 UTC+2, tigr wrote:
> No, that is not "nice". The strength of the CakePHP design is in being > very straightforward when it comes to working with the data. I have seen > other frameworks and I think that object-oriented ways are not suitable for > working with data. Well, of course, you can, but would you want to, given a > choice? My answer was "no" and that is why I am using Cake. I am worried > that the object-oriented hype will get the best of you and we will lose a > perfectly sensible data processing framework to the object-oriented glory. > For practical reasons, it would be great to leave the model layer > principles as they are.
my few cents:
a.) fork it b.) if cake is decoupled enough = forking will be easy (e.g. the decoupling between model layer from controller layer from view helper etc.) c.) instead of forking, add a 2nd model layer abstraction d.) learn from rails3 e.) look at how well AREL works
so for me the questions are rather: can a similar decoupling be done well in php 5.4; can we get true objects or just read only? if we get read only, can't we just enable a bool to return nested data arrays?
For mine, being able to deal with objects in the view would greatly improve
the readability of data (the whole $user['User']['email'] etc looks
incredibly difficult to read to me, compared with $user->email which would
be much nicer).
I've always felt dealing with arrays is a bit of a 'hack'. I understand the
choice, but I think the idea to move towards a more object oriented
approach is more than hype, and long overdue.
On Sat, Jul 7, 2012 at 7:35 PM, tigr <alb...@tigr.net> wrote:
> No, that is not "nice". The strength of the CakePHP design is in being
> very straightforward when it comes to working with the data. I have seen
> other frameworks and I think that object-oriented ways are not suitable for
> working with data. Well, of course, you can, but would you want to, given a
> choice? My answer was "no" and that is why I am using Cake. I am worried
> that the object-oriented hype will get the best of you and we will lose a
> perfectly sensible data processing framework to the object-oriented glory.
> For practical reasons, it would be great to leave the model layer
> principles as they are.
> --
> Our newest site for the community: CakePHP Video Tutorials
> http://tv.cakephp.org > Check out the new CakePHP Questions site http://ask.cakephp.org and help
> others with their CakePHP related questions.
> To unsubscribe from this group, send email to
> cake-php+unsubscribe@googlegroups.com For more options, visit this group
> at http://groups.google.com/group/cake-php
On Sunday, July 8, 2012 7:12:32 PM UTC-7, Greg wrote:
> For mine, being able to deal with objects in the view would greatly > improve the readability of data (the whole $user['User']['email'] etc looks > incredibly difficult to read to me, compared with $user->email which would > be much nicer).
> I've always felt dealing with arrays is a bit of a 'hack'. I understand > the choice, but I think the idea to move towards a more object oriented > approach is more than hype, and long overdue.
> On Sat, Jul 7, 2012 at 7:35 PM, tigr <alb...@tigr.net> wrote:
>> No, that is not "nice". The strength of the CakePHP design is in being >> very straightforward when it comes to working with the data. I have seen >> other frameworks and I think that object-oriented ways are not suitable for >> working with data. Well, of course, you can, but would you want to, given a >> choice? My answer was "no" and that is why I am using Cake. I am worried >> that the object-oriented hype will get the best of you and we will lose a >> perfectly sensible data processing framework to the object-oriented glory. >> For practical reasons, it would be great to leave the model layer >> principles as they are.
>> -- >> Our newest site for the community: CakePHP Video Tutorials >> http://tv.cakephp.org >> Check out the new CakePHP Questions site http://ask.cakephp.org and help >> others with their CakePHP related questions.
>> To unsubscribe from this group, send email to >> cake-php+unsubscribe@googlegroups.com For more options, visit this group >> at http://groups.google.com/group/cake-php
Wouldn't array be still used? For instance more than one objects are
passed, should the objects be stored in an array? What would happen to the
auto conversion to json? Array is easier to convert to json rite?
On Jul 10, 2012 1:19 AM, "Jamescowhen" <x...@splitp.com> wrote:
> I would think moving to a more object oriented model will result in better
> readable code and IDE auto completion will be more useful.
> On Sunday, July 8, 2012 7:12:32 PM UTC-7, Greg wrote:
>> For mine, being able to deal with objects in the view would greatly
>> improve the readability of data (the whole $user['User']['email'] etc looks
>> incredibly difficult to read to me, compared with $user->email which would
>> be much nicer).
>> I've always felt dealing with arrays is a bit of a 'hack'. I understand
>> the choice, but I think the idea to move towards a more object oriented
>> approach is more than hype, and long overdue.
>> On Sat, Jul 7, 2012 at 7:35 PM, tigr <alb...@tigr.net> wrote:
>>> No, that is not "nice". The strength of the CakePHP design is in being
>>> very straightforward when it comes to working with the data. I have seen
>>> other frameworks and I think that object-oriented ways are not suitable for
>>> working with data. Well, of course, you can, but would you want to, given a
>>> choice? My answer was "no" and that is why I am using Cake. I am worried
>>> that the object-oriented hype will get the best of you and we will lose a
>>> perfectly sensible data processing framework to the object-oriented glory.
>>> For practical reasons, it would be great to leave the model layer
>>> principles as they are.
>>> --
>>> Our newest site for the community: CakePHP Video Tutorials
>>> http://tv.cakephp.org >>> Check out the new CakePHP Questions site http://ask.cakephp.org and
>>> help others with their CakePHP related questions.
>> --
> Our newest site for the community: CakePHP Video Tutorials
> http://tv.cakephp.org > Check out the new CakePHP Questions site http://ask.cakephp.org and help
> others with their CakePHP related questions.
> To unsubscribe from this group, send email to
> cake-php+unsubscribe@googlegroups.com For more options, visit this group
> at http://groups.google.com/group/cake-php
On Tuesday, July 10, 2012 3:57:20 AM UTC+2, madi wrote:
> Wouldn't array be still used? For instance more than one objects are > passed, should the objects be stored in an array? What would happen to the > auto conversion to json? Array is easier to convert to json rite? > On Jul 10, 2012 1:19 AM, "Jamescowhen" <x...@splitp.com> wrote:
>> I would think moving to a more object oriented model will result in >> better readable code and IDE auto completion will be more useful.
>> On Sunday, July 8, 2012 7:12:32 PM UTC-7, Greg wrote:
>>> For mine, being able to deal with objects in the view would greatly >>> improve the readability of data (the whole $user['User']['email'] etc looks >>> incredibly difficult to read to me, compared with $user->email which would >>> be much nicer).
>>> I've always felt dealing with arrays is a bit of a 'hack'. I understand >>> the choice, but I think the idea to move towards a more object oriented >>> approach is more than hype, and long overdue.
>>> On Sat, Jul 7, 2012 at 7:35 PM, tigr <alb...@tigr.net> wrote:
>>>> No, that is not "nice". The strength of the CakePHP design is in being >>>> very straightforward when it comes to working with the data. I have seen >>>> other frameworks and I think that object-oriented ways are not suitable for >>>> working with data. Well, of course, you can, but would you want to, given a >>>> choice? My answer was "no" and that is why I am using Cake. I am worried >>>> that the object-oriented hype will get the best of you and we will lose a >>>> perfectly sensible data processing framework to the object-oriented glory. >>>> For practical reasons, it would be great to leave the model layer >>>> principles as they are.
>>>> -- >>>> Our newest site for the community: CakePHP Video Tutorials >>>> http://tv.cakephp.org >>>> Check out the new CakePHP Questions site http://ask.cakephp.org and >>>> help others with their CakePHP related questions.
>>> -- >> Our newest site for the community: CakePHP Video Tutorials >> http://tv.cakephp.org >> Check out the new CakePHP Questions site http://ask.cakephp.org and help >> others with their CakePHP related questions.
>> To unsubscribe from this group, send email to >> cake-php+unsubscribe@googlegroups.com For more options, visit this group >> at http://groups.google.com/group/cake-php
I'm not aware of any plans to make the good parts of Cake worse. We fully plan on keeping things like Convention over config, and features like bake and scaffolding around, perhaps even make them better.
I find it strange that you think arrays are not adequate for configuration, but cite yaml + json as more adequate. Both these data formats parse into arrays. Wouldn't that also imply that arrays are equally good? I know that arrays can have a more finicky syntax than say yaml, but json is equally tedious to edit.
I would be interested in alternative ways to declaratively create validation rules. One reason there are so many nested arrays, is that PHP doesn't really provide many other ways to statically define complex functionality. Perhaps validation rules shouldn't be treated as a declartive configuration type thing, and instead built at runtime using a fluent interface? I think trying to define validation rules in a format like ini files would end pretty horribly.
On Friday, 6 July 2012 17:50:27 UTC-4, the_woodsman wrote:
> I've worked with Cake since the 1.1 release, and recently I've worked a > lot with Symfony, and on larger scale apps, which has helped me understand > the strengths and weaknesess of both frameworks.
> So, a chance to express an opinion on the future of Cake? How could I > possibly resist :)
> (Disclaimer: All of this is just my opinion /POV, not preaching here...)
> Obviously it's important not to throw the baby out with the bath water - > DRY, Convention over config, auto-magic/scaffold features, etc are some of > the key features that differentiate Cake from other frameworks, and losing > this for the sake of a design pattern or a ridiculous amount of abstraction > shouldn't be risked.
> * A clearer Dependency Injection model for core classes. I didn't think > Cake had anything like this then I read a post on overriding the Request > class, and I was like 'is this DI?' SF2 has a DI component that can be > reused for this I think.
> * Appropriate use of arrays. There's a time and a place for arrays, and, > imho, data is a good use, and advanced config is not.
> I love Cake's convention over config approach (vs the bloated yaml files > of Symfony) but when you *do* need that config, arrays won't cut-it for > more complex stuff. > The support for ini files in Cake 2 is a great step forward in this, and, > imho, json, xml, and ini files should be natively supported for some app > config, and similar for value-object creation.
> * Greater modularity - obviously the move to name spaces (and I hope PSR > standards?) is linked to this.
> I think partitioning the folders as per > https://groups.google.com/forum/?fromgroups#!topic/cake-php/msttsVAG9tI, > and making the different libraries work independently, would be ideal- why > shouldn't someone be able to use the SF2 Router and the ZF Controller layer > and the Cake model layer if that's what works for them? Or migrate their > enterprise app over to another framework incrementally?
> For example, take the model layer- Imho, the model later is one of Cake's > best features, and changes should be cautious. > * Standalone library - I think being able to use Cake's model layer as a > stand-alone would massively increase the mind-share of Cake.
> * OO changes - it's a matter of opinion, but Cake's arrays aren't really > a massive issue for me. Given you can usually access arrays with object > syntax, and there's various community behaviors to achieve this effect > anyway, I don't think this a deal breaker.
> Value Objects makes some sense, but I personally hope Cake never goes the > way of $record->save, and always keeps with $model->save. > Imho, putting too much DB behaviour into the row-level objects leads to a > much more complex system, where it's a lot easier to implement poor SQL. > If people want that approach, don't re-invent the wheel, Doctrine and > Propel are mature libs and they don't need any more competitors :)
> One places the models could definitely do with a revamp is the setting of > validation rules.
> Once I'm 4 levels deep into the array config, I wish I was making classes > or objects or using a separate config format!
> Okay, sorry for the rant, but I'd be interested to see how closely my > views align with the community at large...
> On Friday, 6 July 2012 03:36:03 UTC+1, José Lorenzo wrote:
>> Since its creation, more than 7 years ago, CakePHP has grown with a life >> of its own. Its main goal has always been to empower developers with tools >> that are both easy to learn and use, leverage great libraries requiring low >> documentation and low dependencies too. We've had several big releases >> along these years and an ever growing community. Being one of the most >> popular frameworks out there and probably the first one (!) we have also >> gotten a lot of criticism from the developer community in general. We have, >> though, accepted it and learnt from our mistakes to keep building the best >> PHP framework there is.
>> CakePHP is known for having a very slow pace of adopting new stuff and it >> has served very well to its community. Back when we were doing version 2.0 >> we decided to hold on version 5.2 of PHP for multiple reasons and despite >> it didn't let us innovate as much as we wished to, it was an excellent >> choice given the general environment regarding hosting solutions and >> general adoption of PHP 5.3. A look back into the past reminded us that we >> were big innovators in PHP, bringing features to developers that few dreamt >> possible to do in this language. Now, it's time to look ahead in future and >> decide on staying in our comfort zone or take back our leading position as >> innovators.
>> So it is with great excitement that we announce we are putting our our >> efforts in bringing you the next major release of CakePHP. Version 3.0 will >> leverage the new features in PHP 5.4 and will include an important change >> in our models and database system. CakePHP 3.0 will not be ready less than >> 6 or 8 months and we reckon that, given the rise of cheap cloud hosting >> solutions and upcoming release of new operating system versions, there is >> no better time to jump on the most current stable version of PHP.
>> As you may already know, PHP 5.4 offers awesome features that would >> introduce useful new concepts and interesting solutions to old problems. >> Closure binding, traits, multibyte support are tools we see of great >> usefulness for properly implemented advanced framework features we've had >> in mind for a long time. Also new syntax sugar added to the language will >> make it more pleasant to write both small and complex applications with the >> framework and a always welcomed free performance increase.
>> We have a young but already well defined road map for what we want to >> accomplish in next release and you are invited to contribute and suggest >> what's next:
>> - Drop support for 5.2.x and support 5.4+ only
>> - Add proper namespaces for all classes. This will make it easier to >> reuse classes outside CakePHP and to use external libraries and finally no >> chances of collisions between your app classes and core ones.
>> - Use traits were possible and makes sense
>> - Improve bootstrapping process to allow more developer control and >> better performance
>> - Model layer rewrite:
>> - Models to return objects from queries
>> - Datamapper-like paradigm
>> - Richer query API
>> - Support for any database type
>> - Support for more database drivers both PDO and native
>> - Improve Router:
>> - Make it faster
>> - Remove named parameters
>> - Add support for named routes
>> - Smarter router prefixes
>> - Shorter url syntax
>> As you may imagine most of the time will be spent or rewriting the model >> layer, but it will also be one of the most powerful features CakePHP 3.0 >> will have. It's new architecture based on PHP 5.4 capabilities will offer >> an easier and more powerful set of tools to build web applications in no >> time.
>> If you are already as excited as we are this all this new stuff coming, >> you definitely should meet us on next CakeFest <http://cakefest.org/> we'll >> be talking about the future of CakePHP and hacking our way through to bring >> you a dev release as soon as possible. Wouldn't it be lovely to attend to >> awesome talks, workshops and also be part of the group deciding initial >> architecture for next major version of the framework? Make sure you book >> your tickets before we run out of them!
>> We're always looking for different people having a vision on software >> development, are you interested in helping out? There is no better time to >> start sending patches and become one of the core team!
There isn't really an example yet, as no code has been written. Based on this thread it might be a helpful process to go through a public vetting of the proposed model api, and how some common use cases might work. I know that josé has begun implementing basic database abstraction which an api that resembles PDO, but no work on the actual model layer has started.
When I started to build a behavior for queries to return object in place of array (Active Record Pattern for cakePHP, in the bakery), I was not aware of the plans for CakePHP 3.0. But according to the discussion here, some people seems worrying about being obliged of using objects in place of arrays (this would also make application upgrade really difficullt or nearly impossible). Wouldn't be wiser to let the developer to decide whether he wants arrays or objects? And to propose for example an integration with Doctrine (or to enhance the behavior I wrote)?
Thank you anyway for your hard work to improve cakePHP!
Op vrijdag 6 juli 2012 04:36:03 UTC+2 schreef José Lorenzo het volgende:
> Since its creation, more than 7 years ago, CakePHP has grown with a life > of its own. Its main goal has always been to empower developers with tools > that are both easy to learn and use, leverage great libraries requiring low > documentation and low dependencies too. We've had several big releases > along these years and an ever growing community. Being one of the most > popular frameworks out there and probably the first one (!) we have also > gotten a lot of criticism from the developer community in general. We have, > though, accepted it and learnt from our mistakes to keep building the best > PHP framework there is.
> CakePHP is known for having a very slow pace of adopting new stuff and it > has served very well to its community. Back when we were doing version 2.0 > we decided to hold on version 5.2 of PHP for multiple reasons and despite > it didn't let us innovate as much as we wished to, it was an excellent > choice given the general environment regarding hosting solutions and > general adoption of PHP 5.3. A look back into the past reminded us that we > were big innovators in PHP, bringing features to developers that few dreamt > possible to do in this language. Now, it's time to look ahead in future and > decide on staying in our comfort zone or take back our leading position as > innovators.
> So it is with great excitement that we announce we are putting our our > efforts in bringing you the next major release of CakePHP. Version 3.0 will > leverage the new features in PHP 5.4 and will include an important change > in our models and database system. CakePHP 3.0 will not be ready less than > 6 or 8 months and we reckon that, given the rise of cheap cloud hosting > solutions and upcoming release of new operating system versions, there is > no better time to jump on the most current stable version of PHP.
> As you may already know, PHP 5.4 offers awesome features that would > introduce useful new concepts and interesting solutions to old problems. > Closure binding, traits, multibyte support are tools we see of great > usefulness for properly implemented advanced framework features we've had > in mind for a long time. Also new syntax sugar added to the language will > make it more pleasant to write both small and complex applications with the > framework and a always welcomed free performance increase.
> We have a young but already well defined road map for what we want to > accomplish in next release and you are invited to contribute and suggest > what's next:
> - Drop support for 5.2.x and support 5.4+ only
> - Add proper namespaces for all classes. This will make it easier to > reuse classes outside CakePHP and to use external libraries and finally no > chances of collisions between your app classes and core ones.
> - Use traits were possible and makes sense
> - Improve bootstrapping process to allow more developer control and > better performance
> - Model layer rewrite:
> - Models to return objects from queries
> - Datamapper-like paradigm
> - Richer query API
> - Support for any database type
> - Support for more database drivers both PDO and native
> - Improve Router:
> - Make it faster
> - Remove named parameters
> - Add support for named routes
> - Smarter router prefixes
> - Shorter url syntax
> As you may imagine most of the time will be spent or rewriting the model > layer, but it will also be one of the most powerful features CakePHP 3.0 > will have. It's new architecture based on PHP 5.4 capabilities will offer > an easier and more powerful set of tools to build web applications in no > time.
> If you are already as excited as we are this all this new stuff coming, > you definitely should meet us on next CakeFest <http://cakefest.org/> we'll > be talking about the future of CakePHP and hacking our way through to bring > you a dev release as soon as possible. Wouldn't it be lovely to attend to > awesome talks, workshops and also be part of the group deciding initial > architecture for next major version of the framework? Make sure you book > your tickets before we run out of them!
> We're always looking for different people having a vision on software > development, are you interested in helping out? There is no better time to > start sending patches and become one of the core team!
