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.
I'm new to backbone.js and am working my way through some tutorials. I've found a couple that seem good, but there are some inconsistencies in how they implement so I'm looking for a little guidance on best practices.
Here are the tutorials I'm learning from:
http://www.jamesyu.org/2011/01/27/cloudedit-a-backbone-js-tutorial-by-example/
http://coenraets.org/blog/2011/12/backbone-js-wine-cellar-tutorial-part-1-getting-started
My questions are:
The first tut makes use of Backbone.Controller but not Backbone.Collection. The second does the opposite. Which is the best practice for the "C" in backbones spin on MVC?
The first tut defines urls in the Model, whereas the second defines it in the Collection. Which is the better practice?
The second tut makes use of Backbone.Router, while the first one does not. Which is best practice?
Alternatively if someone can suggest a better intro tutorial that follows best practices I'd be happy to learn from there. Unfortunately because of the inconsistencies between these two, I'm concerned I might be learning some bad habits out of the gate.
Thanks in advance.
Backbone.Controller was renamed to Backbone.Router last year. I guess you were reading an old tutorial.
BackboneTutorials.com is a decent tutorial for getting started.
Build a small app as you learn and you'll know what Backbone does for you.
The best way to learn Backbone is to go through the annotated source code. Each and every line is commented and explained.
Use the dev version instead of the minified version when building your app. This helps in debugging.
If you are into reading books, check out Addy Osmani's Backbone Fundamentals, a free e-book. The book is awesome, but quite verbose. You can use it as a reference.
See this question on Quora for the definitive list of resources;
Don't worry too much about what's 'V' and what's 'C' and backbone's spin on MVC.
The framework does an excellent job of separating code that interacts with the server and the code that performs the core client logic. Templating and updation of DOM Elements is left to you. It's pretty minimalistic in that sense. Backbone provides Events that make the different parts interact with each other.
this is a good question. Though, Backbone isn't taking position on how you should organize your code.
So, the real answer is: it depends.
It depends on the need of your application and how you're used to program.
If you want an overview of some best practice, I'd refer you to the Backbone Boilerplate project: https://github.com/tbranyen/backbone-boilerplate
This project is pretty solid, and really helped me out when starting.
Then, to answer your question (this may feel opiniated, and it is indeed):
1: Backbone is mostly an MV* framework (Model-View-Whatever). Controller logic mostly live into Backbone view, and this is OK for front end developpement as logic is often really tied to the UI (as we are mostly coding interfaces). Backbone isn't coming built in with controller, but if you prefer this type of organization, just build your own.
2: Urls depends on your need. If you're fetching a full collection, set it up on the collection, if you're only fetching (or probably saving) one model, set it on the model. These too live well together.
3: About Router, if you're building multiple pages/sections on your app, use them. But beware of not using routes as action as you would do in RESTful APIs, this will most of the time brings problem eventually (user press back button, etc). So, use routes if you want to manage pages.
Hope this help !!
I will answer from experience:
Q: The second does the opposite. Which is the best practice for the "C" in backbones spin on MVC?
A: There is no Controller in current Backbone http://backbonejs.org/ - "C" happens either in View (most cases) or in Router (see below).
Q: The first tut defines urls in the Model, whereas the second defines it in the Collection. Which is the better practice?
A: There are cases when you don't need collections. In case when you don't, your model absolutely needs a URL. When you do have a collection, URL you specify for Collection will apply to its models.
Q: The second tut makes use of Backbone.Router, while the first one does not. Which is best practice?
A: Rule of thumb - you want to use Router in 2 cases: 1) when you want to have history, and 2) when you want to have permalinks. Otherwise you don't really need router.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I wanted to get into full-stack JS development. I was about to start with the usual MEAN stack (MeanJS). I stumbled upon these articles:
http://wiki.dandascalescu.com/essays/why_meteor http://wiki.dandascalescu.com/essays/meteor_js_vs_the_mean_stack/
That are convincing. I am really confused how to get started. What are the pros and cons of using a frontend-backend-database framework like meteor over the conventional MEAN?
Due to the nature of the question, I'll try to answer it broadly. After using the MEAN stack for over 2 years and Meteor for a few months, I much prefer Meteor.
If you're just starting, Meteor has amazingly simple conventions. Try the angular-meteor tutorial to get started. Meteor offers one line installs, perhaps most notably including user authentication. You get the power of observables & latency compensation as a default.
The MEAN stack requires much more configuration and setup, as well as a strong developer foundation in Node.js. You have to do the work, but it may be worth it to understand the full stack. Much of what Express handles in dozens of lines of code can be handled in one line of code in Meteor.
Having said that, it is sometimes difficult to hack together Angular with Meteor. For example, I'm currently having difficulty using the new-angular-router with overlapping Meteor conventions. Consider MEAN has a much longer trusted history and wider support.
I think you are going to get a lot of opinionated answers, but to be honest every user is different and you won't really know until you try each out. I took a look at all the tutorials that were available for the ones that interested me.
ReactJs:
I was never a fan of reactjs, until the 3rd time I went through the tutorial, and thought this is kind of easy to get the hang of :
http://facebook.github.io/react/docs/tutorial.html
ReactJs is a framework by facebook and is doing pretty well. It works by updating the DOM and the syntax reminds me of that of programming a game. It uses states and props.
AngularJS:
I didn't prefer angular js as much because I didn't really give it much of a try (atleast more than twice). I was hypocritical about it. I thought of it as too much to remember and the tutorial I tried with it was this one :
https://thinkster.io/mean-stack-tutorial/
I think it is a great tutorial to get you into the stack. I can't say much about it but Angular 2.0 is coming out soon.
MeteorJS:
I never gave it a full go, but it looked interesting and from what I read, it was mobile friendly and great for single page app. Recently I've been following this tutorial:
https://scotch.io/tutorials/building-a-slack-clone-in-meteor-js-getting-started.
This is the next project I'm going to try to do in Reactjs(in meteor first).
I think its all really preference and you should just give all of it whirl. Some might be better at some functionality then others, some may be more syntax friendly, some may just be easier to use. All depends on the type of person you are.
Since Meteor is built upon NodeJS, it may be obvious that it was created to enhance development over the MEAN stack.
Meteor relieves the pain of writing hundreds of lines of code to accomplish a simple real time app, for example.
So if your question begins with "I wanted to get into full-stack JS development...", I strongly recommend you Meteor over MEAN.
At the end of the day:
"Meteor will be the JavaScript framework that will rule them all"
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Learning angular is a pretty frustrating process. I've just started the journey down this endless road a couple of weeks ago. I've gone through the official tutorial on the angular website, watched the first 40+ videos on egghead.io and read through several other tutorials and examples. I'm new to angular but have a good amount of experience with javascript, jQuery, and knockout, but even after all of the research and examples I've gone through, I still can't piece together even the simplest angular app in a real-world situation.
The problem is that most of these tutorials and examples try to show all the different parts of angular, including controllers, directives, filters, services, $http/$resource, routing, animations, etc.so you end up with this one or two controller app that doesn't have any substance but it incorporates the basics of all of these features. Now, strip away all of the features that aren't really needed for a simple app like $resource, routing, and animations, and add substance to the business logic and data management, and you quickly can see how many holes exist in these tutorials.
For example, a tutorial will show how you can share data between controllers using services. It will go over creating the controller, and using a service to get the data from a server using $http or $resource. Then it will show that even though the request for data is asynchronous, there is rarely a need for callbacks because the data-bindings will just be empty until the data arrives and then magically filled in. Now you have a reusable service to get data in all of your controllers.
Wow! everything is so simple and clean, and it just works! Angular is awesome! Then, of course, when you go to write an actual app that needs more than one controller, and the controllers all depend on the same data, and you add something called "business logic" that is also shared and uses this data, you immediately realize things aren't so simple.
First of all, as soon as you add business logic that has to use the data from the server (like with any real app), your clean code with no callbacks is broken. You now have to implement callbacks everywhere, because you have to wait for the data to arrive before you can use it. Second, prototypal scope inheritance becomes unreliable because you don't know if the data from other controllers has loaded yet or not. Worst of all though, there is nothing in these tutorials about how you are supposed to keep the data in sync between controllers, and with the server. If the data is modified in the scope of one controller, somehow all of the other controller scopes need to be updated as well...
These are just some of the complexities that are introduced even with a pretty simple app that doesn't even use routing. I'm trying to make a simple calculator that doesn't persist data, and I am stuck with all of these problems and questions and can't find any real solutions.
Can someone please point me in the right direction of a good tutorial, example, or book that will fill in these missing holes without getting into complex parts of angular that my app doesn't require?
Thanks in advance and sorry for the rant, this has been very frustrating :/
I am far from being an angularJS expert, I am actually in the process of learning too. However, we are almost done with our first angularJS MVP at work so maybe I can share some of my experience. Here are a few patterns I learnt
Your controllers should be minimalist and call services and factories.
Controller actions are triggered by $emit and $broadcast which is what keeps everything in sync. I have controllers with just a list of $scope.$on('onCustomAction',function(event,params){ $scope.myObject.doSomething(); }). Ideally, it should be a minimalist list of those.
In ng-click, you should have methods like myObject.fancyMethod() where myObject is part of the '$scope`.
Put small pieces of reusable html that have their own little controller in directives. I am quite late on that but I am starting to have a few.
Use ng-include for large pieces of html that you need to move around (ie: modal windows, main content, sidebars etc).
Remember, if it's not in the $scope, it might as well not exist.
Services can call other services and can be used for singletons and instanced objects. They should be the meat of your code.
Hope this helps. Feel free to argue each of those items.
As someone who was experiencing the same type of angularjs frustration. I get it. What helped me immensely was Jeremy Howard's 4 part tutotial, "Angularjs End to end web app in under an hour". It uses ASP.net but I am sure most of the back end examples would be easily reproducible with any other framework.
Here is a quick and dirty laundry list of why I found this useful.
Example is a Todo CRUD app that could be used as a template for most other web apps.
The videos move at a reasonable pace and are broken down into logical functional areas.
Jeremy uses some of the techniques you described above that are in other videos such as promises, directives, factories, services, link functions, controllers, etc. However, the examples he uses do have substance as they work within the context of the todo app.
Lastly, it becomes clear in watching Jeremy going through his tutorial that being very organized in how you structure your back end will make your front end angular app so much better and powerful. Think separation of concerns to a whole other level.
I could go on and on but one thing I can say, is that Jeremy's tutorials not only made me better at angularjs but made me better at being a full stack developer.
Do yourself a favor and check it out. You won't regret it. Good luck.
Here is a nice tutorial on data model dealing with your problem:
"Worst of all though, there is nothing in these tutorials about how you are supposed to keep the data in sync between controllers, and with the server. If the data is modified in the scope of one controller, somehow all of the other controller scopes need to be updated as well..."
http://www.webdeveasy.com/angularjs-data-model/
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 9 years ago.
What pitfalls/ problems/ pains might I expect as I start building real and more complex apps with Angular ?
I am at a new job and about to recommend Angular (and Bootstrap) as the basis for building all our web apps. After nearly 1.5 years of working with backbone.js I know I don't want to use it... We have a Node + MongoDB back end and no real investment in any client side stack. One unique thing is that we have some big data - one collection that will reach 10's of gigs in size with hundreds of millions of records... I have been reading up on and playing with Angular for past two weeks or so and haven't really found anything bad about it.
There is really no pitfall :)
On to a likely less zealot explanation: AngularJS is (as far as I've been able to tell) a lot more opinionated than backbone - most processes are dead easy to perform (displaying data, processing interactions) but follow a somewhat stricter pattern to do so. Supposedly it makes angularJS harder do bend to your specific criteria than backbone, but I have found it isn't so. Also, the few shortcomings of the system are quickly disappearing, as it is evolving crazy fast.
Point in case: the routing system is one of the lesser aspects of angularJS, as it is generally not very flexible (no route inheritance, no state machine)... I started making apps using a workaround that turned out to be quite clean, explained here. However, the folks at angular-ui have come up with a solid solution and a similar solution is bound to appear in angular itself.
The animation directive was also a shortcoming (animating the appearance and disappearance of objects is tricky, as they need to exist up until the end of the animation, and that has to be managed) and has also workaround solutions, but a core animation system was introduced in the 4th of april in angular 1.1.4, here, so you see, it is rapidly evolving :)
Regarding learning curve: it has some, but nothing someone with your experience can't handle in a very short time. This series of video tutorials is the best resource i know of, as an easy way to understand the gist of most things (the documentation is good enough and getting better, but lacks applied examples in some places where it would really helped - or lacked, they may be better by now - also, the "beginners tutorial" is dreadful, I personally hate long running, step-by-step tutorials)
Hope it helps!
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.
I've been getting a similar feeling lately. I felt this way several years ago when I had been using Apache, Django and MySQL exclusively. I felt like the web stack that I was using had began to show its age. So, back then, I switched to Nginx, Flask and MongoDB. I'm starting to feel like this stack is showing its age again, because I'm hearing about tons of new cool things that sound easier in newer stacks.
For example, I'm hearing a ton about Backbone.js as well as client-side templates, like Mustache. These seem to be able to make use of URL hash bangs and produce pretty awesome sounding applications.
I've been toying with Node.js, Express.js and Mustache.js for templates (I do not like Jade). This setup feels like something that I can get familiar with, because it reminds me of Jinja, which is what I used with Flask. This still does not include Backbone or client-side templates. But, how do I know what a good scenario to be using those when I see it? Is Backbone and Mustache on the client something I should be investing time into? How do I know when I should use them and when I shouldn't?
If I switch to this newer stack, I think I'd still be generating my HTML on the server just like I am with my current stack. How do I make the switch to client-side templates, and why, I guess?
you probably won't get a clear answer on such a question,
it is more open and not a real code problem, you have a big chance this gets moved over to another spot. but untill then it doesn't hurt to give my answer to it.
nothing wrong with generating html on the server,
even the sites with huge javascript injections like google+ and such, still render much of the markup on the server.
the use of backbone, in my opinion depends on which site / app you wish to make, that alone says it already,
the first big thing i ask myself is, am i making an application? or a website.
while some sites can benefit from backbone's, i believe an application is where backbone shows in all it's glory. When creating a website i would end up using backbone for a bit of structure, but not the full deal models, collections, views and routers.
on the templating engine, you need to choose your engine for 2 reasons:
am i comfortable writing how this engine works (syntax, not too much javascript inbetween my html (loops and such))
can my engine do what i want it to do (in certain occasions you want nested templates, some engines don't do that, ...
the first is less important than the latter, syntax can often be changed, some engines support a config where you setup the syntax either {{}} or <%= %> or something you make up yourself.
Use backbone.js...
when you create a medium to heavy web application,
and only when you have working restful api returning json
Use client side templates...
when you can fill them with data from a json object,
and you want to leverage caching of layout and structural content on client, and only fetch the data from server
This isn't a technical answer like the other answers, but will give you other perspectives to consider.
You should definitely be using Backbone or other client-side framework because speed matters for the user experience. The faster the experience, the more time people will spend on your site. People don't like to wait and people are more engaged when something is fast. There are few things that kill engagement faster than waiting.
Why Backbone?
You are already familiar with MVC, so there's nothing new to learn in that respect. With an MVVC framework like knockout, you'd have to spend time grokking that pattern.
It's one of the most popular client-side frameworks. Lots of people are using it and there are tons of resources out there to help you learn. I've put up a list of companies using it in production here:
http://www.quora.com/Can-we-get-a-poweredby-list-of-sproutcore-javascriptmvc-backbone-js-individually
Because it is the most popular client-side framework relative to others (Sproutcore/Amber.js, Spine, Knockout.js, Cappucino, etc.), there is plenty of documentation.
As far as a templating engine is concerned, I recommend that you don't bother with anything except the John Resig micro templates that are already part of underscore.js (which is the only hard dependency besides either jQuery or Zepto.js). Picking up another templating engine is one more moving part to worry about that really doesn't make that much of a difference. It's also trivial to switch from one templating engine to another. Switching is a half day to a 2-day project for a small to medium-sized project.
I think I can see where you are going with this. Personally I think NodeJS, ExpressJS, MongoDB and MustacheJS are pretty good together.
You can create a webpage as you normally would. Use MustacheJS to place the fields where you want the data to show up in the markup.
Then on the NodeJS side, you can use express to route to the html file, gather the data from mongoDB, use mustacheJS to parse the file and then spit it out to the client.
It's pretty straight forward.
Here is an example of doing just that I wrote not too long ago:
NodeJS, ExpressJS and MustacheJS Template Engine
As far as the data is concerned, I'm using a standard object but that can easily be replaced with a mongoDB data set.
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.