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! > -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
