I just read a lot of the replies and noticed major pushback on the change to the model layer (data array to object). Now I'm sitting here completely perplexed as to why anyone would think that data arrays are a good choice for accessing the model over traditional objects?! I've worked with CakePHP for about 4 months now and everyday I bang my head against the wall because of how these darn data arrays pervade EVERYTHING.
Look, using data arrays the way Cake does now, you are coupling your database schema to your model, your view, and usually your controller. Change one name in your schema and now you have to go change every other artifact that comes into contact with that data (yes I know you can bake stuff but maybe I don't want to lose all that hand-coded view functionality, or maybe I just don't feel like rebaking my app because "user_name" just became "username"). Perhaps the problem is that many people have forgotten why OOP exists in the first place. One comment event mentioned how arrays can be accessed via object notation so who cares about using objects....seriously? Objects don't exist so you can use dot notation, they exist to separate dependencies on behavior from dependencies on data. Business logic should depend on other business logic, not architecture logic. Changing queries to return objects is an absolutely necessary upgrade, IMO. I would even go further to say that the term "model" in CakePHP is grossly mis-used. A "model" right now in Cake just means a query machine...but a "model" should be any object of significant business purpose which abstracts the behavior of the application (because if its not a View and its not a Controller, it must be a Model). I have all sorts of "models" in my apps that I can't call models because their job is not to run CRUD operations. I believe the current concept of a "model" in Cake should be shrunk to something like a model.data package so that we can more easily include pure models which focus on business behavior over the very specific task of querying databases and other data sources. Said differently, we should be able to think of our models only in terms of their interface and still have a perfect understanding of what the system does. Anyway, BIG thanks to the Cake team for understanding the importance of object based queries. I can't applaud that enough. The one thing I might suggest is a little bit of public effort to educate everyone about the reasoning behind this change....it seems to me that a lot of people are reacting on some emotional attachment to data arrays instead of thinking about how this actually makes our lives easier without adding work. On Thursday, July 5, 2012 10:36:03 PM UTC-4, 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! > -- You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com. To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/cake-php?hl=en-US.
