My impression is that CakePHP 3 was all about revisions to the model layer, plus a chance to drop support for unsupported releases of PHP, and take advantage of newer language features.
-- I've only been using CakePHP since 1.1, and I still have a few major projects in the wild using CakePHP 1.3. I've been wanting to upgrade to 2.0, and if the client ever does want that to happen, perhaps I'll go straight to CakePHP 3, if it's available.
For me, the benefits will be using namespaces in PHP 5.4, and not having to bother with plugin name juggling. Namespaces have been available since PHP 5.3, but now that they're actually supported in CakePHP properly, I can also use them in my apps, knowing that the deployment platform also needs to be running (at least) PHP 5.4. With CakePHP 2, I'd try to do development using PHP 5.3, but sometimes deployments ended up being on PHP 5.2 platforms.
There's also benefit in separating the Model into the Table and Entity. It can reduce what was once a very fat model, and split into location services (on the Table) and entity business logic, on the entity. I'm hoping there's performance benefit in using collections of objects over arrays.
I think it will be about the same for speed and ease of developing apps, but I'll get to learn some new tech along the way (like composer, traits, closures). Whilst scaffolding will be gone, there will still be bake, providing the same utility as before.
I'm not sure that a migration from v2 to v3 will require any less of a rewrite than v1 to v2. Two things that stood out for me in migrating v1 to v2 was the unit testing library (SimpleTest to PHPUnit) and helpers ($html-> to $this->Html->). Whilst there are now migration scripts for v1 to v2, I seem to recall they might not have been available immediately. With the release of v3, it might be that we'll be able to hit the ground running with migration scripts ready to convert models to entities and tables.
I'm fairly excited about the evolution of the framework. I don't think CakePHP 3 will be a complete departure from CakePHP 2. It's just an older, wiser version of the framework.
Secretly, I'm still hoping that CakePHP gets to a point where you can selectively install components of it, to assist with the migration of legacy code. Usage of composer and namespaces are a definite step toward that direction, although might not be something that the core development team would ever want to actually do.
I totally agree with your last point. Alternatives should always be considered.
On Monday, 6 January 2014 10:44:07 UTC+10, bbf wrote:
On Monday, 6 January 2014 10:44:07 UTC+10, bbf wrote:
This is the first time I've read about the reasoning behind the major changes to 3.0. (for background I've been coding PHP since 1999, using Cake since 2008, and "cakephp" is the only tag I follow on Stackoverflow ;) )
What are the strategic goals of Cake v3?
Grow adoption of the framework be switching to "more modern" features? Do you feel more developers will give it a chance because it supports features like traits, closures and an object-oriented ORM? I'm trying to understand why all the breaking changes are being introduced.
What are the benefits (not features) to devs in v3?
1) Make it faster to develop apps?
2) Make it easier to develop apps?
3) Make it faster to get started for new-to-Cake devs?
4) Increase features for current Cake devs?
5) ?
Maybe I'm dense or not understanding the ramifications of the new features. Reading this latest announcement, it seems like v3 just makes changes for changes sake. You guys all love coding and it's fun to work on the latest cool features of PHP -- I get that. You're adding lots of "features" that take advantage of new stuff. But how much of it translates into actual *net benefits* for current developers?
Will an OO ORM make Cake easier to code? Faster to code? Faster to interpret/execute? Do things that were impossible before with the non-OO ORM?
You mention stuff like "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." How do namespaces, traits, and closure bindings help a dev "build web applications in no time"?
I've been using Cake since 2008. Cake v3 feels to me like I have to re-learn Cake from scratch due to the *huge* amount of breaking changes. It feels like v3 is a whole new framework.
All my current apps can't be upgraded. All the custom generic components/behaviors/plugins I've written over the years which I use for *all* my current/future projects will need to be re-written. All open-source plugins will need heavy re-writes (unlike v1.x -> v2).
Those facts totally negate the "features" of v3 for me and is pretty demoralizing. I might as well start also considering other frameworks if I'm being forced to scrap all my current plugin code. If the slate is clean there is no reason for me *not* to consider other frameworks. Cake may still end up being the best option, but with previous version changes I didn't even bother considering the other options because of the relatively easy migration.
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP
---
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscribe@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment