I've used CakePHP on several projects in the past, and have more recently started using Ruby on Rails, but there's a new project I'm about to start that will require PHP. While refreshing myself on CakePHP I learned that there is a new framework called Lithium that is essentially what CakePHP 3 was going to be. It's being developed by a group of former core CakePHP devs.
I haven't found a whole lot of information about it since it's still under development status, but I was wondering if anyone knows (or has a link to) some information on what benefits it provides over CakePHP. Hopefully something a bit beyond the quick overview shown on the official site. I'm trying to decide whether to use CakePHP for my upcoming PHP project or to wait a bit for Lithium to release a non-development version and try that out.
Hope this answer doesn't come too late, (and as the lead developer of Lithium, I'm a little biased :-)), but I will say that this is a hard thing to sum up. Lithium is the culmination of over 4 years' experience building and working with CakePHP, and while it retains many of the same designs and conventions, it was built to correct CakePHP's many architectural flaws.
In brief:
Framework features are grouped into loosely-coupled "packages" that are easy to use independently.
Tangentially, everything in Lithium is a "library", including your application, and Lithium itself. Support for integrating 3rd-party libraries is vastly improved, and all classes are namespaced, so you can finally have a model called File.
It is very easy to swap out core classes with your own custom implementations.
Lithium has a unique "filter" system that allows you to hook into many methods in the framework, which allows you to design your applications in an aspect-oriented fashion. These features work together to make Lithium the most flexible PHP framework, bar none.
Everything is lazy-loaded, and the architecture has been designed for maximum performance.
Lithium supports the latest tech, especially new databases like CouchDB and MongoDB.
I could go on for a while, but that's the gist of it. If you have any more questions, feel free to drop by #li3 on Freenode, and someone will happily give you a tour.
There is very little documentation so far. Here are some brand-new slides from gwoo though, that might be a good overview:
http://www.slideshare.net/gwoo/li3-ocphp
See the Lithium about page in their wiki. It lists all the features it will provide.
http://rad-dev.org/lithium/wiki/about
Related
I'm a project manager of a market place and I'm trying to find solution for my concerns. For two years a ago we decided to develop market place.
In front layer we decide to use angularjs and our team professional implement front layer using AngularJS. We add dependency injection for first time to angularjs 1.3 and solve google analytic crawling in SPA website.
But when google announce On July 1, 2018 AngularJS entered a 3 year Long Term Support period. As a project manager I have a big concern because We living in 2019 and after two years whats happen for our website ?
But my biggest question is how optimistic how long can we use Angularjs?
how much migration is necessary for this framework and
Is it possible that the sites written with Angularjs are not able to work after 2021?
Google announced:
All AngularJS applications that work now, will continue to work in the future. All published versions of AngularJS, on npm, bower, CDNs, etc will continue to be available.
For more information, see
Angular Blog - Stable AngularJS and Long Term Support
AngularJS Version Support Status
It’s out of date now, and new projects should absolutely not be built using it. This isn’t to say it was ever a particularly great choice. AngularJS came out of nowhere and became popular by default, rather than because it had particularly great design. It has a difficulty curve better suited to a great roller coaster than a decent framework, and a bunch of weird architectural and terminology choices. What the hell is a $scope, anyway? And what is a directive? What does transclusion actually mean? Meaningless terms that AngularJS has created. AngularJS does some things that are fundamentally wrong, such as creating invalid attributes on HTML markup. Even Google doesn’t use Angular for their own apps, like Gmail, and there’s a reason for that.
In fairness, AngularJS was always a poor choice. Its idiosyncratic code means that unlike other frameworks, it’s not good at implementing an agnostic, javascript solution. AngularJS code looks unfamiliar to anyone not super experienced with the weird intricacies of AngularJS itself.
Thankfully, this decision is well made for you – AngularJS is now quite thoroughly dead, and only legacy projects will continue to be using it. We should be grateful for what AngularJS has given us, and respect the position it held, but we should be just as pleased that it’s gone.1
The change is only about "support" and it means, no more bug fixes and no more improvements. Other than that, everything will be the same. Although, you should consider some disaster scenarios after LTS.
I saw some posts about running AngularJS and Angular side by side and I think it can be a good solution for your problem. Since you have enough time to migrate, your team can develop new features on Angular and you can also maintain your current AngularJS. Eventually you can get rid of AngularJS depending on your project size and development capacity.
Please check these scenarios.
Running AngularJS 1.6 in Angular 5 (side by side)
Running Angular and AngularJS frameworks side by side
For Angularjs support, you can find the previous discussion on this portal: angularjs 1.x support lifecycle and end-of-life
And the question regarding migration, in my personal opinion migration is a better option as the latest Angular version provides Boost in performance, Mobile-driven approach, code Maintainability & optimization, and most importantly Reduced development time and costs with better support.
And if asked about the migration approach, I would suggest a complete re-write that can be the most cost-effective strategy. If you’re a manager, put your team through Angular training (live, online, videos, books). Allocate time and budget for getting your developers up to speed with Angular as the learning curve is steep and prior experience with AngularJS is not overly helpful. Then your developers will write the new version of the app as per best practices recommended for Angular/TypeScript projects.
And finally, it’ll definitely pay off in the end. And, secondly, the newer versions of Angular won’t let you systems become outdated or irrelevant.
There is a team called XLTS.dev who are providing extended support for AngularJS beyond December 2021.
We have used Angular JS extensively in our company for enterprise projects, mobile applications and continue to use it. Google's decision to stop development of AngularJS and put it on a EOL will definitely make developers to panic. But 3 years to migrate away from it is a long time and you can plan accordingly.
If your plan is to migrate to Angular, then you can follow their official guide to upgrade using ngUpgrade. You can find numerous articles online that explain how they upgraded existing AngularJS apps to Angular.
If your plan is to consider migrating to a totally new framework, then this will involve some work. You should take a look Web Components spec. Your existing directives/components can be re-written, with less effort, as web components (shadow DOM) or custom components (without shadow DOM). There are libraries that help you write these generic components - supported on most browsers today - Stencil JS, lit element and a few others.
The advantage of using Stencil JS is that it provides tools to compile your web components to target different frameworks (Angular, React, Vue, Ember).
The latter solution seems feasible as it allows you to migrate directives one by one over a period of time, without having to re-write the whole application in one go. In the future you can also re-use your components in the framework of your choice.
As for your question about will it continue to work after 2021 - yes it will continue to work. The problems you might face might not really be of technical nature, but related to hiring resources to work on it or maintain it.
I am AngularJS developer and I do continue to use this framework for some of my projects. I am aware that in not too distant future this library will be completely outdated (as some of you can say it's the case now), however:
AngularJS ecosystem gives you still lots of choice/support (as framework is very mature)
my main libraries as ag-grid, highChart or others, help to build great apps out of the box with little time
I still do enjoy to work with this framework for it's simplicity and flexibility
If you should build brand new app I would recommend React or Vue (or other framework) especially if you do not have significant experience with Angularjs. However if Angularjs is not new for you, you need to go fast - just use your experience and go for Angular.
Taking into account what you wrote:
My main concern is after 3 years of support. Whether after the 3 year end of support, Angularjs sites can continue to work without problems
Angularjs apps won't just stop to work like that, from one day to another.
As your project requires long-term maintenance, needs to be built from scratch and will take lots of effort - Angularjs ecosystem is then probably not the best choice for you (I do insist "for you").
I have little by little built a website over the course of the past year and am now at a stage where the whole thing can go commercial, which means that I will face some tough questions regarding security, privacy, etc.
Since this is a situation where a hobby turned into a possible professional product, I am now rethinking how far I have to take this in order to really provide a product that is considered "safe" and stable.
The website was put together based on a Bootstrap 3 theme design, runs mostly on HTML, JavaScript, jQuery, PHP with Mysqli interactions and naturally has a SSL certificate. About a dozen plugins from various websites such as datatables, PHPmailer, jQuery-bootstrap-upload, blueimp gallery, etc. do the things I need them to do and I have always paid attention to properly mysqli_real_escape input values and write error handlers for all interactions. In short, there is no real framework here, things are more thrown together.
I am now being challenged that this is not considered a safe/stable solution and instead should recreate the whole website based on the CakePHP framework, which is something I am not familiar with and will take a fair amount of time to get used to and will definitely screw up my timeline.
So in short what I am asking is this: How important is it for a small and relatively simple website (i really dont do any complex code here...) to be built on a framework such as CakePHP in order to be perceived as safe and secure?
I understand there is no real answer to this, but I was just wondering whether building on an established framework like CakePHP is considered the only way to go or if a custom made framework is acceptable.
Thanks for the advice.
I was in your situation a couple years ago. I had started a site that, in the first year had about ~50 unique visitors. The second year I had about ~1500 unique visitors. What does this mean to a developer.
Optimize the response time - caching.
You need to optimize how you fetch data. Can you cache some queries? - CakePHP comes with caching Redis, Memcached etc.
Multiple Datasources - ElasticSearch, Mysql, Redis
Now that my website is huge, visitors might start to demand more functionality from the website. How do i deal with multiple datasources? CakePHP offers ways to interact with multiple datasources like ElasticSearch, Mysql, Redis
Code maintenance - Raw code vs a Framework
Do I need to google, and stackoverflow to reinvent the wheel? CakePHP comes with the best templating system and helpers.
Cutting down on development time.
If I am coding everything myself - I will spend more time developing. Using CakePHP I spend more time improving my website's data.
Decoupling
Does my data need to be managed by Cakephp, can I use Django, REST APIs etc. In the end I decoupled my website. I use Django to manage data entry, and CakePHP to present the data to visitors using Django REST framework.
No one can tell you definitely use CakePHP. However CakePHP3 , in my professional opinion, has a short learning curve. Using namespaces you can still use your current code in CakePHP and transition slowly into using CakePHP fully. CakePHP documentation is very good. You should be able to get a basic site wrkoing within an hour.
I'm considering using the Agile Toolkit, ATK4 to upgrade a number of web projects that I'm working on. I really like the idea/paradigm that the Agile Toolkit presents, but I'm worried about documentation.
The agile website's documentation is sparse, in broken English, and seems to 'paraphrase' the symfony documentation.
The agile toolkit alleges to have been in development/production since 1999, yet there are only a handful of StackOverflow.com posts regarding agile, and next to nothing comes up in Google searches...
In short is it worth spending time learning the Agile toolkit, or would my time be better spent on a framework that has more of an active support community? I've tried a few other frameworks, but ATK's implementation really stands out...
Initially ATK was born as an internal tool from Agile Technologies (.ie) so that has been conceived in 1999 but it was recently launched as dual licensed framework.
That's why it lacks some documentation and has not a huge community nor appears Googling.
I was amazed at first sight by its working way proposal so that I engaged it. The documentation has been already improved and over the time it will keep getting better and community will grow.
I had the chance to get in touch with the lead developer and trust me, it will get better and better.
Even, as an example all the ATK4's site is developed with the toolkit and the code is short and pretty easy to read.
Good luck!
ATK4 does have many examples, and code is concise and clear. It accomplishes the goal of wrapping server-side and client-side into one comprehensive framework via php. Plus it looks nice. It does appear that documentation is improving.
Yep - agree with what the others are saying - Romans is doing a great job of getting the documentation updated. I started writing an application in straight php but realised i was going to need to use jquery to get a nice, cross browser compatible front end and wanted a php framework that would support that.
I looked at Yii, Cake and CodeIgniter but ATK4 really seems to do what i wanted. Like anything, it takes a bit of getting used to and i'm still relatively new to both php and ATK4 but i've rewritten what i already had for my application in the framework and the code is so clean - all the html and css are separate and the page code is really compact. The integration with Jquery is great and i've just written a plugin that i needed to get jqplot working for nice looking graphs.
I was trying develop a website with Cakephp and Joomla... But lately I've been founding a lot of barriers that create difficulties implementing things that would have been a lot easier if I only developped using one of the components.
So, in your point of view (as someone with more experience than me), is it worth to integrate CakePhp with a CMS?
If yes, what do you think its the best and easier CMS to integrate with?
Or use Croogo (http://croogo.org/)
A CakePHP CMS. I like Croogo's implementation more than Wildflower and the admin UI looks a bit similar to Wordpress.
From my point of view i wouldn't try. I think there would be a lot of crossover functionality and a lot of conflict. Either use Cake and write a CMS and the other elements you want or pick a CMS and develop the other elements you want as add-ins/plugins.
Joomla, Drupal, Xaraya, Expression-engine etc are all extensible so pick the one that is the best fit and has the ability to be extended or maybe already has plugins you require.
Another option would be to use Joomla as the CMS and Cake for the other element you want, keep them as separate entities but skin then identically and make the navigation seamless. In this case about the only thing you would need to integrate would be state.
There are some out there already that are on Cake from the ground up. Wildflower for example
http://wf.klevo.sk/
I have a cakephp site that is running wordpress in it's public_html/blog folder and it is doing great.
They are basically two separate sites, with two separate backend but it is fairly easy to create a model for the wordpress database if you want to pull in any data (eg. posts, pages, comments) and use it in the cakephp site.
As far a integrating the two I don't think it is a good idea if it needs to be a seamless experience for the backend users, most frontend users won't notice the difference because you can use the same style sheet and images.
If you want any more about my experiences with the combination let me know!
Cakeui is a rip of Croogo. Infinitas CMS could be what you're looking for if you want a full blown application or check this site for a list of good CakePHP Cms
As the developer of Croogo, I will be biased and recommend you to check it out at http://croogo.org. It comes with a web based installer too and you should be up and running in minutes.
Another CakePHP based CMS is Infinitas which has more features (including shopping cart). Both are based on the latest version of the framework (1.3 at the moment) and are actively developed.
I wrote a lot of CMS type apps with Cake and was thinking along the same lines. I've tried Joomla, Drupal and Wordpress but still had a dirty feeling in my mouth that I was failing by using Cake just for the sake of it or vice versa.
The most important common denominator, in my experience, is the back-end. It is re-used most often, but gets the least input.
Now I have built my own CMS with CakePHP. The intention is to 'opensource' it, but it's not quite ready yet.
I don't think it is worth the headache trying to combine, then maintain Cake and a 3rd party CMS. Save your best modules and components and build your own. The blog tutorial will give you a good head start and you can cherrypick what you like from other sources, rewriting it to suit your ideals. The benefit is you will then know the CMS inside out and have it working just the way you want. You'll learn a lot along the way as well.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is conceptually the difference between symfony and cakephp?
Just to balance out this thread, this is why I like symfony:
uses PHP5
it runs some really big sites like Yahoo! Answers, delicious, and Daily Motion.
good documentation. the jobeet tutorial on the website is awesome. walks you straight through all of the features, and after you are done you feel like you can build anything.
is highly modular; many of the symfony components work on their own.
allows you to choose either Propel or Doctrine as your ORM. Doctrine is really great and easy to use.
you can define your models with YAML or in PHP, its up to you. Some people don't like configuration files, and you can really limit their use if you want to steer clear of YAML.
the updated symfony cli (as of 1.2) is awesome. I agree with abales, before this version it was a little wonky, but now it is very well documented and follows a predictable format.
there are a lot, and i mean a lot, of similarities with ruby on rails, except that of course PHP isn't quite as pretty or flexible as Ruby(!). But, if you talk to a cake developer, they will probably say the opposite :)
the symfony admin generator, which is a step up from CRUD (which also exists in symfony), is a huge time saver. Using your data model it will generate customizable admin interfaces complete with list views (index), create, and edit pages. It's not like basic crud where it generates the source and you go in and modify it... You actually can define how each field looks, which fields you want to include, what additional actions you can perform on each object, and so on.
Conceptually, I'd say the difference is this:
CakePHP has a smaller learning curve. If you have never used a MVC framework, Cake will be easier to pick up and run with in a short amount of time.
Symfony feels bit "bigger," not to say that it is slow, but that there is a lot of code back there that will let you do a lot of really advanced things when you need to.
The best advice I can give is to quickly try to set up a your own simple data model in both, and experiment with some basic interfaces, and just see which fits your own coding style the best. I think both frameworks have very active and passionate user communities and you won't regret your decision either way.
CakePHP philosophy is similar to Ruby on Rails.
CakePHP is better for medium projects.
CakePHP is faster to learn.
CakePHP is lighter than symfony.
CakePHP's Database Interaction uses CRUD.
CakePHP uses the test system PHPUnit.
Is interesting in CakePHP Bake and scaffolding.
Symfony's philosophy is each version is different.
Symfony's is slower to learn.
Symfony's is best for large projects.
Symfony's Database Interaction uses Doctrine.
Symfony's uses the test system PHPUnit.
Is interesting in Symfony's Bundles and templates.
A big difference is in how models are created: CakePHP models are written in PHP, and Symfony models are written in YAML and powered by Propel. CakePHP's approach is more similar to ROR's ActiveRecord (although it isn't exactly an AR implementation). CakePHP, in general, is more rails-esque.
CakePHP's documentation and tools, in my opinion, have a wider target audience and the syntax and helpers are easier, but thy have yet to embrace PHP5 as their exclusive target (to autoloading isn't really there). In general, I prefer CakePHP's approach because it sort of follows an established standard, and I applaude it's organization. I'd also recommend Kohana for it's PHP5 goodness.
There's another post on stack overflow about this question, although its a bit different in focus.
Edit: I revisted Symfony to find the reasons I said 'no' and came up with these — your opinions and mileage may vary:
CakePHP also offers dead simple scaffolding and easy to understand CLI tools. Symfony's CLI syntax is a bit wonky to me, and 'CRUD' in Symfony just isn't the same. Combine that with Symfony's (awkard) action syntax and throw in Symfony's poorly designed (and challenging to understand) website, and preference for 3rd-party paid documentation (books on Amazon) and you have more ticks in the cons column.
Some of the claims about CakePHP and limitations above simply isn't true. The query is possible. You just have to know how to make it. The "automagic" of CakePHP is SUPER nice so you can hit the ground running FAST. It is BY FAR the FASTEST framework to development (hence why it's so closely modelled after RoR which obviously was a big success and buzz). There are more advanced behaviors to get data returned differently and make some of those more complex queries with a few short method calls and array parameters specified.
However. As far as I can tell, no other framework has as many "automagic" methods and classes. Cake takes the most common of tasks and provides an easy way to get it done. If you're really clever, you'll do most of your coding at the model level and make use of the app_model and app_controller file and have an extremely efficient application.
The console is great and always expanding. The community is truly amazing and there are many many contributions to help you get things rolling even faster. You can literally architect and then move "pieces" into place to build an app very quickly because most of what you'll need is available. You do not get that with any other framework. You have to spend a LOT more time coding usually.
Lastly. While the documentation was lagging, it is much better now and while Cake also got some harsh reviews during this lack of documentation and version 1.1 period...It was STILL good, just severely overlooked. With 1.2 and now Cake2 and Cake3 on the horizon...You're going to see a lot of opinions changing.
I have used CakePHP since 1.1. I'm a firm believer in it. I have used it for huge corporate sites. That receive millions and millions of hits per day...We're out of the realm of things like WordPress and Drupal for solutions. When you get to that level for a CMS type site, I am super glad to have CakePHP on it. Likewise, Symfony and CodeIgniter will help you with the scaling. I can't say anything bad about either of those frameworks either. I can only say that you will spend less time coding and find a larger community (and a super friendly IRC channel) with CakePHP.
I'm going through and documenting some of my responses to the above comments about CakePHP and some of it's (in some cases rightly) perceived faults.
Big websites are run using CakePHP, some being Mozilla Addons, Scratch by MIT, and Hot Scripts. There is a bigger list right at the bottom of the CakePHP website (http://cakephp.org). Regardless, any good developer should be able to build a scalable website using a framework as long as the framework isn't completely silly (CakePHP isn't too silly :D ).
It is true that there isn't one very good (free) CakePHP tutorial that goes through every feature of the framework, but the documentation is extremely well laid out and verbose. Anything that isn't clear can be cleared up through the Google Group and on IRC, and we welcome any and all changes/corrections to the documentation. Documentation is not just a core developer issue, as many things are application specific and people come up with interesting tips and tricks, and so thusly everyone is invited to contribute (Not just comment!). Of course it is all moderated, so most of the cruft/spam is not added.
The code is modular in that you can add in new code that supercedes core functionality. Much of the code is simply PHP classes. It is true that writing such functionality may be a burden, and I have not tried using alternate classes as fillins. Yes, it does not handle other ORMs, so you are stuck with the default, but this should be fixed in Cake3, which will be able to mix and match any other PHP classes at will (that includes Propel and Doctrine support).
The CLI is very good, and it is easy to extend for App-specific support. One example is that I recently developed a shell plugin that would automatically install any other CakePHP plugin that I have indexed from github. Took about 5 hours to build something extremely usable and flexible. I'm sure such functionality exists for Symfony, and it DOES exist for RoR :)
As for being Rails-like, it is and it isn't. Many things are similar, they are MVC frameworks after all, and CakePHP goes for the "Conventions vs Configuration" approach. PHP4 support mucks with a nicer syntax, which Symfony doubtless has because of PHP5-only support, but it is still extremely usable and intuitive. The framework does not provide EVERY feature of Rails out of the box as it isn't a straight clone. CakePHP is a framework, not a library (hi Zend), so it won't provide everything out of the box.
Generation of views is, I agree, a bit wonky in CakePHP. It is being greatly enhanced in CakePHP 1.3 and 2.0. It will support custom templates for each and every Model, View and Controller (as opposed to just a type of view as it does now). Also, there exists a set of shell tasks on github by a user going by neilcrookes that auto-bakes only certain types of views (including only admin views) which can be used in combination with custom templates to produce exactly what you want. CSS styling also helps :) but this is definitely something that can be improved.
CakePHP takes many varied parameters in it's Model::find methods, although in certain cases it may be useful to use raw SQL queries. The Model::find() method is very flexible and has not failed me insofar as creating complex finds. I suppose that is related to being comfortable with the ORM, which inevitably always takes time.
Form validation should logically be in the model layer, as that is where any action related to the database is being performed. You can specify alternate validation in a specific view I believe, or swap validations (there is a behavior for this but it wouldn't be hard to do so without it).
Multidimensional arrays are a bit silly, but you'd still likely have multidimensional objects. PHP4 had a broken Object Model and so that is why CakePHP does not use objects. This is being corrected in a future version of CakePHP (as I pointed out above in a previous comment), but it is useful to have a framework that supports PHP4 in some cases. Again, YMMV and I agree that full PHP5 will be a great boon, both in speed of the application and of development.
Databases can be swapped out at will. CakePHP does not allow functionality that is inherent in only one type of DB (hence the dropped support of ENUMs that are only in MySQL), so that the ORM is always supported and can always build valid queries. You can have multiple databases in an application, one per each Model if you wanted, and can swap them at will or even not use a database at all for a specific model. So no, it is not tied to a specific database.
In the end, your choice is your own, and I wholeheartedly suggest looking into both and reading through the documentation, checking out the Groups, IRC channels, blogs and any forums for both and seeing which framework suits your development style the best. Reader beware, I'm a CakePHP developer so my post has some bias.
Further to the existing answers, you should try both if possible. I use both quite a bit, and over some time, have come to prefer symfony.
but I'm fairly convinced that its not because one or other is better, but because symfony happens to suit the way my mind works better, its closer to what I do when I write software outside a framework, so feels more intuitive. I expect that others may find their mind fits the paradigm of another framework.
Having said that, I do think that cakephp's objects are a weakness, through the use of arrays rather than objects. (This is something that periodically develops into an intense hatred inside me whenever I need to do something that it makes hard ... ! ) They could do exactly the same, but return objects rather than arrays to represent data, and I think most of the issues I have would go away - you'd be able to add extra functionality into the data objects to achieve the things I want to do, rather than writing functions in the existing model class and passing them an array.
The model layer of CakePHP is a mess. Try doing simple things like a many-to-many relationship between a Category and an Item object and then retrieve all the Items in a Category that have a specific property set.
Like:
SELECT items.* FROM items, categories, item_categories WHERE item.available=1 AND category.id=1 AND item_categories.category_id = category.id
Something so trivial is not possible in one statement in cake with the find() method of a model.
There is also no way in the core API to add a single many-to-many relationship as in one item to the item_category table above. There are a couple solutions online including a behavior that someone posted in the bakery (http://bakery.cakephp.org/articles/view/add-delete-habtm-behavior), but that's just stuff that any good ORM framework like Propel, Torque(Java), Hibernate(Java), SQLObject(Python), SQLAlchemy(Python) support right out of the box. Basically you're either going to have to write a lot of PHP code to add those missing features or use raw SQL queries but the main purpose of a framework is to avoid doing those things so that you can focus on the application that you're writing so you're not really gaining much with CakePHP.
There are a bunch of other problems and they all really have to do with the model layer including the form validation being tied into the model layer, having to deal with messy multidimensional arrays, having to use raw sql and tying your app to a specific database.
I would say use symfony. It's a bigger framework might take a few days longer to learn but it will be well worth it. I was going to use CakePHP for a project that I am working on, after running to too many of those types of issues I switched to symfony and it's been smooth sailing.
One difference more is: Symfony separated to 3 environments: Development, Production and Testing - CakePHP can not!
It's easy to develop and test product at same time
Cake 2.0 nicely autoloads most of the classes you need, whereas I found in Symfony 2 that every class had to have numerous imports at the top of the script. Attempting to memorize all those imports is near-impossible, so you always need a reference handy.
eg. Symfony 2 controller code...
namespace Acme\HelloBundle\Controller;
use Symfony\Component\HttpFoundation\Response;
// bunch of other imports accumulate here...
class HelloController {
...
Argh, yuck. While that may be good OO technique for the purists, it lengthens development time (bye bye RAD). At least with Cake I can code most of the simple stuff quickly from memory now.