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 <[email protected]> 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 > [email protected] For more options, visit this group at > http://groups.google.com/group/cake-php -- 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 [email protected] For more options, visit this group at http://groups.google.com/group/cake-php
