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.
BACKGROUND / IDEA
I am currently working on a small framework just to improve my php-knowledge. This framework should be very simple (minimizing overhead) and flexible in terms of later expansion.
DIFFERENT MEANINGS
As a result of reading more advanced tutorials, notes of serious php-developers, different class structures (singletons, Singletons, dependency injection, JIT, ...), oop, mvc, routing, caching... and a lot more I find it very difficult to filter "the proper way" (if there is one) as it seems to me that everyone says something different.
Many people praise there opinon as "the best" and say that everything appart from that is evil. In my oppinion there is not a right or false. There are just several ways to achieve one's goal.
WHAT I DID SO FAR
index: ini settings, define constants, call bootstrap (not oop)
booting: autoloader class, namespaces (include files on demand)
static classes: htmlManager, fileHandler, databaseManager, ...
singletons: none
non-static classes: controller, models, views, routes, ...
I know that this is very basic and I did not that much so far but I want to create a solid platform first.
QUESTIONS
Before I want to go any further in my project I'd love to hear your opinion on the things listed below.
How do you organise/structure small or even bigger projects?
What are your experiences concerning simplicity, logic, performance, readability, expandability and reusability of code?
Is there really a "proper way" of coding or it this just interpretation?
Is there anything one should not use because it is already obsolete?
WHAT I DON'T WANT TO HEAR
Forget about a framework or php
Don't do this, don't do that without naming the reason why
Many thanks in prior for every response I get.
I am currently working on a small framework just to improve my php-knowledge. This framework should be very simple (minimizing overhead) and flexible in terms of later expansion.
Go for it.
As a result of reading more advanced tutorials, notes of serious php-developers, different class structures (singletons, Singletons, dependency injection, JIT, ...), oop, mvc, routing, caching... and a lot more I find it very difficult to filter "the proper way" (if there is one) as it seems to me that everyone says something different.
That's because some people don't have an understanding why something should be solved in a certain way or why something is terrible practice, but they see something on some framework and they think it's the best thing since sliced bread.
Although opinions may differ, you cannot argue with clean code and proper OOP if that is what you are after. In proper OOP singletons and statics have no place. Also what most people call MVC is actually some wrong view on the pattern (mostly because again they have seen some framework do it some way). Which is not always bad, but it is not MVC.
Many people praise there opinon as "the best" and say that everything appart from that is evil. In my oppinion there is not a right or false. There are just several ways to achieve one's goal.
Not everything that isn't the best is terrible in my opinion. But some stuff is just bad practice. And some pattern are defined in a way to make your applications easier to maintain, debug and test. If you are going to implement some other pattern that's all fine with me, but you will loose the benefits of some other pattern.
Generally speaking the first rule of thumb I use when doing OOP programming is following the SOLID principles.
static classes: htmlManager, fileHandler, databaseManager, ...
These have no place in proper OOP. Amongst others because the will tightly coupling the classes. Which make maintainability, readability and testability a pain.
singletons: none
Good, because they are just a fancy global.
How do you organise/structure small or even bigger projects?
Separation of concerns in both code as structure. One of the pattern can help you with that: MVC, MVP, [MVVM](Model View ViewModel). For me personally I like the MVC pattern the most because it has some nice benefits against other patterns.
What are your experiences concerning simplicity, logic, performance, readability, expandability and reusability of code?
Readability and testablity are the most important.
Right after that SOLID (which is also handled by the first point (overlap))
Is there really a "proper way" of coding or it this just interpretation?
Is there anything one should not use because it is already obsolete?
Performance
Forget about a framework or php
Don't do this, don't do that without naming the reason why
As I stated before: Just go for it. Do it and screw it up! Best way to learn is actually doing it and making terrible mistakes. I think the framework I made 1 year ago (although imho still better than 90% of what is out there) is a proper piece of crap ™.
How do you organise/structure small or even bigger projects?
Many PHP frameworks use the MVC structure.
What are your experiences concerning simplicity, logic, performance,
readability, expandability and reusability of code?
Beside strict following of MVC I would suggest following principles like KISS and DRY. I would not consider performance as a high priority topic. You can get yourself familiar with caching strategies and good algorithms later (general topics, not PHP).
Is there really a "proper way" of coding or it this just
interpretation?
There are some things that could be considered as best practice, you will find many hints on popular frameworks like Zend or symfony.
Is there anything one should not use because it is already obsolete?
You'll have to find out for yourself. You could skip writing a database handling and use ORM libraries like doctrine or propel. You could choose a special template engine for your view-representation like twig or smarty.
Don't do this, don't do that without naming the reason why
I think all long-time PHP programmers started their own framework at least once, there is no argument against it, especially not if you want to improve your knowledge.
Related
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.
We're using ORM in PHP on our team, and I've noted in two separate projects that, even though we've specifically talked about good MVC design at length, that ORM appears to be allowing people to do DB queries from the View layer and creating difficult-to-maintain code.
I'm leaning towards the opinion that ORM makes it too easy to make queries under the covers that the programmer doesn't think about. By returning ORM objects to the view layer the programmer is essentially leaking a database connection to a layer that should not have it.
Am I thinking about ORM correctly here? If so, why is it so darn popular? If I'm not thinking about it correctly how should I address these issue?
I'd say that you're not thinking about it correctly. ORM by and of itself does not promote bad practices, at least, not in the way you're experiencing it.
ORM is a tool, just like any other framework, api or whatever, you can use it correctly or not.
It sounds more like the problem is that the developers in your team doesn't have a clear understanding of the MVC pattern. I'd start with addressing that issue first.
I think it's quite a common problem with the MVC pattern that developers tend to use the views and controllers for things that they aren't supposed to do. The reasons might be many, but whenever you work with something like this, I beleieve the problem usually starts with something similar to this thought:
"It such an simple little thing I'll just do it here instead, there's
no point doing it all over there."
Basically when trying to decouple design and business logic there will always be situations when it's easier to implement some piece that actually belongs in the business layer in the presentation layer. It mustn't mean that the developer is bad, but it might show some lack of experience or laziness. I know I've been guilty of this exact thing several times, like when developing for Android (never professionally though :)).
How about trying to figure out some sample-case that uses some of the bad practices that you've noticed and have some sort of coding-dojo where you as a team make that code nice and correctly implemented, and if you have time, show the actual benefits of having stuff where they belong. I'd strongly advice against using actual code unless you've written it yourself or the developer responsible for that code is okay with being mangled in front of other devs. But this obviously depends on the culture in your company and if the developers are interested and open for these kind of things. I personally would love having similar things at my workplace.
I don't know that having small ORM calls in the view layer is necessarily bad. For example, I might have foreach (Category::getAll() as $Category): as the loop to list categories on a page. The connection doesn't leak into the scope of the view (or at any rate it certainly shouldn't) since it is encapsulated by the ORM. I could assign the result of this call in the controller and pass the array of objects to the template (and I certainly will with more complex calls) but imo trivial cases are fine in the view.
The biggest problem with ORMs in my experience is the growth of "n+1" database query counts. Normally a one:many list on a screen can be rendered from a single query, but ORMs make it extremely convenient to use a primary loop with one table, and then to do an individual select for each instance of the secondary table. This is inefficient, but you'll only notice when your database starts to creak with the expanded number of queries it is having to deal with.
The best guard against this is to ask your developers to run a toolbar in dev mode (such as the Symfony2 toolbar, PHP Debug or similar) which shows them the number of queries required to build a screen. When trivial screens start needing more than 50 queries (or whatever ceiling you specify) then they need to refactor.
Also, it's worth choosing an ORM that has a reasonably expressive query syntax, otherwise your devs will be shirking back to "raw SQL" mode, which defeats some of the reasons of having the ORM in the first place. For the same reason - and Daniel makes this point well - offering training to your devs on using ORMs effectively is a great idea.
Doing queries from views is a bad practice. You can do it, but is better doing it through the controller via Ajax Requests or whatever you consider suitable.
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 12 years ago.
Now days most of PHP web development companies use PHP frameworks or open source products for developing websites but is that a right approach? If so but what will happen to the PHP programmer skill and knowledge?
Don’t you think using approaches such as “PHP frameworks or open source modification” will kill the programmer skill over the time? Is that really worth it a website developer becomes a better PHP framework writer instead of being a better PHP programmer?
I absolutely have to disagree here. When is started programming, it was PHP and I had no clue what I did. I wrote everything myself and had no will to even look at framework. I spend way too much time in work that repeated again and again.
Frameworks are one of the most useful tools IMO (not only web frameworks)
They speed up development in lots of ways
Looking at the sources, I learnt more about good practices, design decisions, directions to think to
Taking bits and pieces of the framework and use it in other apps where the use of a framework is not possible
They help you focus more on your work (MVC, DRY, KISS, ...) instead of fiddling around with the basic
Most established frameworks have a huge user-base and are very well tested.
I think looking at other code helps you be better and more efficient over time. SO is a very good example of this.
Using a framework doesn't make you a weaker programmer, otherwise I could argue you should write you next web app in assembeler, not much fun.
A framework should be thought of more like an extention to a language, a DSL if you like. For example CakePHP is just PHP with extra cool-stuff that makes handling databases and sessions "cake" - excuse the pun.
By using a framework you take the 'yuk' out of preogramming, and allow yourself to treat data as objects, for example.
If you still feel you shouldn't use a framework, then write one, then use it! By this reasoning you should also go and rewrite the PHP libraries and interpreter, however I don't recomend it.
In my opinion, I don't think frameworks "kills the skills" at all, instead it allows skills and more creative workflows to develop, which ultimately leads to enhanced skill. Also, the understanding of how large scale applications are developed are increased with effective use of well developed frameworks, which is definitely a big plus in the end too.
It allows applications to be developed more quickly and efficiently; and the end result is what matters. If you write PHP and don't know assembly, it doesn't mean you've lost your skill - you've simply focused on a higher level of technological progress in this modern age.
I think it's important to know some of the underlying concepts, such as creating and interacting with databases, OOP, design patterns. Frameworks can introduce you to these concepts without making you learn everything at once. They also have the advantage of several thousand hours of development time already invested, a community of testers and bug fixers, etc.
Anecdotally, you hear stories of people starting with a framework and slowly replacing parts of it as they optimize sections of their site. They distill the framework's operations down to their specific requirements. You can't take this route if you aren't a strong programmer.
Frameworks allow you to do work without reinventing the wheel. And the people working on this framework are probably a lot smarter than you, and they have spent a lot more time thinking about the code.
At the end of the day, it's about getting things done. Any given individual may be more productive with a third-party framework, or without. But a framework is the conclusion of any large project, whether you end up creating it yourself or you rely on the work of others.
To work on PHP based framework, you need to be a better PHP programmer.
so, your skill level will increase and it will not decrease...to tell with an example.
We can start writing all the program in assembly language, why do we use high level language...? If you find the answer for this, then you will get the answer for this problem too. :-)
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 13 years ago.
Back when I was learning HTML, I loved how easy it to build pages and arrange everything just the way I wanted using tables.
Then I moved to CSS and learned that you could quickly swap designs without recoding your page. With just a few CSS changes your HTML designs could go from one theme to another and any element could become any other! With CSS I could design spans that looked like images!
Moving from HTML to CSS expanded my concept of design by implementing what I would later learn is modularizing things - just like MVC.
I am now a very competent PHP programmer who is thinking about Ruby. Most of the stuff I pull up on google is PHP vs Ruby rants which don't truly help anything. They are two different languages and take their style from different points. PHP looks like C++ strlen($string) while Ruby looks like server-side JavaScript. str.len()
I want to know the top 3 things about ruby that could really open my eyes as a programmer and justify the time I know it will take to pickup and master a new language.
Please, no mention of abstract things
like language maturity, or obvious
library's like AR which exist in both
languages.
MVC is now used in almost every web
programming language so it doesn't
count either. It is also not
sufficiant in and of it's self to
cover everything. MVCLLCC
(Model/View/Controller/Library/Locale/Cache/Config)
is more accurate.
:UPDATE:
Apparently there isn't too much new in Ruby compared to the other languages I use. Blocks appear to be nothing more than functions with a different name. procs seem to be blocks with callbacks which would be like a hooks system. MVC, AR, and everything else is already in the other languages.
However, I believe the most exciting thing I have seen is that you can open up classes at runtime and add new methods! This is a very important concept and really removes some hurdles that PHP has. No longer do you need extend child classes just to add a few methods to a parent class.
Well, you cut out a few of the things that make Ruby really fun, so I think any remaining list is going to be somewhat arbitrary. Here's why I think Ruby is nicer to work with than PHP:
Consistency: In Ruby, everything is an object -- even numbers. You call a method on an object the same way -- there aren't really any "special cases". Moreover, the standard library (and most 3rd-party libraries) have consistent naming schemes and styles. The PHP library has grown...organically, and as such, the names, use of underscores, etc., is chaotic.
Functional-style programming: Ruby borrows a lot of constructs from functional languages like Lisp. This is a pretty arbitrary reason, but I like functional programming, so having easy access to functions like the map and fold* methods from Lisp and Haskell is a plus for me. It also makes heavy use of blocks (aka "closures") which not only open up some very nice programming styles, but also allows you to write some very general code that can be used in a very specific manner, depending on your needs.
True OOP: Ruby's OO model is borrowed heavily from Smalltalk, and uses the message-passing style rather than the method-calling style. This lets you do pretty cool things like implement your own handlers for missing methods. Ruby is also dynamic in nature, and thus lets you define methods -- and even entire classes -- on the fly, at runtime. You can also "open" classes up and provide your own methods, which can save yourself the hassle of, e.g., extending the String class just to add a rot13 method.
RubyGems: RubyGems is a package manager for Ruby gems (third-party Ruby modules). It makes installing, managing, and removing third-party modules (and their dependencies) a breeze. (I threw this one in as a bonus reason.)
Lambdas (blocks).
Mixins.
Heavy use of the above two concepts in the standard library.
I would also nominate continuations (callcc), but they seem to be relatively obscure (which is a pity), and are gone in 1.9.
Top 3 things about Ruby that I enjoy:
Blocks and procs
Metaprogramming
Enumerable module (tons of awesome Array goodies)
Its hard to stop at 3 but maybe others can add more.
Best thing is try some code out for yourself. Good luck and have fun.
Here's at least one reason that applies to me (maybe you too): The way ruby handles object-oriented programming has "freed" my mind a lot in terms of how I think about coding and architecture. Everything is an object with ruby...
Ruby is fun to read and write
Blocks are even more fun
RUBY IS JUST PURE FUN
I'd say give it a try. I was once a PHP coder too and then switched to Ruby and never looked back. The only downside is the documentation which is clearly better in PHP (I would even say PHP has one of the best)
Here are the three things I really like.
I am not going to speak about the language itself but of what I like in the ruby world in general.
Tests
A lot of frameworks are available. If find them simple. Far easier than anything I have tried in JAVA.
The ruby community is very test-centric and you can find very good screencasts and tutorial to get you started.
It has changed the way I code.
Rails
I believe I started (seems so long ago :)). With Html+tables then CSS then PHP etc.
2 years ago I discovered Rails. And I really think It is an amazing framework.
From my point of view it is the best by far if you do Web Development.
I am curious so I have looked at other things like django, CakePHP, Zend etc but I have never find something as good as rails. Of course it is a matter of taste but I strongly advise you to try it.
Rails is not only an MVC. It is an easy to use MVC.
Ruby != Rails.
But Ruby gained an huge increase in popularity with Rails
Readable syntax
exit unless "restaurant".include? "aura"
You can try to take this interactive online tutorial (15 minutes) to see if you like the syntax.
Ruby is a general-purpose scripting language which has been incorporated into web design, and PHP is a language created for use in web design. (that's not a pro or con for either, merely a point of clarification)
If you already have experience scripting with using Ruby, it's easy to take the next step and incorporate it into your web design (as a corollary, it's also easier to pull Ruby code out of your web design and test it as a standalone script)
For many people/projects, the differences aren't monumental enough to warrant starting over with a new system. I'm somewhat of a Ruby evangelist but I would have to say if you already know PHP well, you will likely do better to stick with what you know. Certainly do not completely re-write a working PHP web application from scratch in Ruby without a lot of thought. This is a source of frustration for a lot of people (as you have probably read in your aforementioned rants) that can unfairly leave a bad taste in your mouth about a language or framework
Ruby is relatively new.
Therefore most tutorials using Ruby are using the latest best practices.
It does a lot of things differently to other languages, so it's a language you either love or hate. I personally am not a fan of it, and I'm sure a Ruby fan will come along soon and give a long list of advantages. And shortly after that, this question will be closed as subjective.
Ruby block is totally awesome!
You can create a DSL ontop of it and improves code readability which you can not achieve with anonymous function. One trivial example is like this:
def it(expect)
yield expect
end
it 'should do as I want it to be' do |this|
puts this
end
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 am mainly looking for good development practices specially when working in conjunction with mysql. I searched through the questions but could not find any related questions. I would appreciate if some one share their practices and wisdom gained through experience.
Apart from some coding standards, I am also looking for design standards and common architectural practices.
Background: I started my career with Java, and over the years I moved to C#/.NET space. I have been practicing architect for over 3 years now. Just added this to give some idea to people.
I would suggest that you familiarize yourself with the history of PHP, I know that doing so has given me a much greater appreciation of what PHP is today and where it has come from.
In short, PHP was written by Rasmus Lerdorf to provide simple wrapper functions for the C code that was actually doing the heavy-lifting so that he could have a simpler language / syntax for writing templates that needed to behave dynamically. The growth of PHP and the community which surrounds it is best described as organic. And much like other things that grow organically, its more than a little messy, asymmetrical, and downright non-congruent.
Once you understand PHP and its community, you need to embrace PHP for everything that it is and everything that it is not. This idea was best presented by Terry Chay in his article PHP without PHP. He's specifically talking about the concept of funky caching, but he captures the concept of coding for PHP as if it were PHP and not (insert favorite language here) better than anyone I've ever seen. In other words, don't try to make PHP into Java, C#, Ruby, etc because if you do you'll fail and you'll hate your life.
Take a look at
How is PHP Done the Right Way?.
I must say that you must first, last, and always avoid the tendency of most beginning PHP developers to use the spaghetti-code anti-pattern. In other words, if you find that you're writing code that contains sql queries, manipulation of data, validation of data, and html output all in a single php script, then you're doing it wrong.
In order to avoid this, it will be helpful to learn something about the nature of web-oriented design patterns. This of course precludes a familiarity with object-oriented programming. But once you've learned the basics of object-oriented programming in PHP, study the MVC design pattern. You don't have to implement this exactly but using the basic ideas of Model-View-Controller will allow you to avoid the blob script problem that most newbies tend to create.
On this point, I would strongly recommend that you take any code snippets you find on the web with a grain of salt. And even if you find it in a book you'll have to consider how old the book is. PHP as a language has advanced quite a long ways and you can't just take code samples at face value because, depending on their age, they may be using workarounds that were valid in 3.x or 4.x but simply are no longer necessary with newer features.
One great thing to do is to study the various frameworks out there. Evaluate what you like and what you don't. Maybe even work up each of the quickstarts that are provided with the framework documentation so that you can start to get an idea of what you like and don't like. And I would strongly recommend that you review the code from the frameworks as well as several other open-source projects so that you can get a feel for how others do things in PHP. Again, take it all with a grain of salt because every PHP developer has their own pet peeves and nuances and none of us is right all the time. In fact, most of the time with PHP there are going to be several pretty good ways to do something.
If you want to get a better understanding of the patterns that are being implemented by the frameworks and are commonly thrown around in the common vernacular on SO, I would suggest that you read Fowler and GoF. They'll teach all about the basic design patterns you'll use in your development efforts.
Specifically watch for the following:
Function files that contain LOTS of functions. This is most likely representative of a need to either put functions directly in the scripts that need them or it may also indicate an opportunity to create some more generic functions that can be made to fulfill the roles of a couple of highly specific functions. Of course, if you're building cohesive, well-encapsulated classes you shouldn't run into this problem.
The do everything class. This is a blob anti-pattern and is really nasty. In this case you need to identify where cohesion and encapsulation are breaking down and use those points as opportunities to break up the class into several smaller, more maintainable classes.
SQL queries that don't use parameterized queries or at least escaped parameters. Very, very, very bad.
Any instance where validation is not being performed or is only performed client-side. When developing for the web, the only way to keep your site and your users safe is to assume that everyone else is a black hat.
A sudden obsessive desire to use a template engine. PHP is a templating language. Make certain that you have clear reasons for adding another layer onto your website before using a template engine.
For further reading please look at the following:
PHP Application Design Patterns
Defend PHP -- useful to give you an idea of the most common criticisms.
Security of strip_tags and mysqlirealescapestring
What should Every PHP Programmer Know
How to Structure an ORM
Best Way to Organize Class Hierarchy
Main Components / Layers of PHP App
Why use Framework for PHP
Recommended Security Training for PHP
Use a coding standard.
Use unit testing. PHPUnit and SimpleTest are the major xUnit systems in PHP.
Be object oriented.
Use version control. Any version control, just use it.
If applicable, use a framework. Zend, CodeIgniter, Symfony, and CakePHP are the major ones.
If no framework, at least use an ORM. Propel and Doctrine are the major ones.
Document. Heavily. Use PHPdoc or similar.
There are a wealth of tools out there for PHP. Please use them, and write good maintainable code. You'll make everyone happier.
Use PDO or mysqli. Using one of these will give you prepared statements, which are safer and more efficient. I can't believe how many examples and tutorials I see using the ancient mysql interfaces. PDO would also make it much easier to switch to a different database system, should you decide to try postgres for instance.
You might look into using Doctrine (http://www.doctrine-project.org). It has a bit of it's own learning curve, but provides very convenient functionality. The handiest parts, for me, are the table creation/test data loading functions. Personally, I prefer to write my own SQL and execute it with PDO, and not use an ORM much in production.
Mainly, learn about SQL and MySQL. http://www.kitebird.com/mysql-book/ this book is excellent. The PHP aspect isn't very intense; PDO takes care of most of it.
Zend Framework's "Coding Standards for PHP" is good starting point. Check also this post.
Your from a Java background, and much of the OO stuff in PHP is very Javaesque. This means many of the design patterns you (hopefully) learnt in Java also apply (to a lesser extent) in PHP. An example for database access would be the DataMapper pattern.
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 almost never hear the word CakePHP without hearing the word Rails shortly afterwards. Are these two frameworks mainly similar based on how they adhere to the MVC model or do they have other significant similarities/differences?
One of the main attractions of Rails for me is how easy it is to do Ajax. Would that also be true of CakePHP?
CakePHP is like a cheap, bastardized ripoff of Rails. It tries to be like Rails without doing any of the stuff that makes Rails great. It kinda feels similar, I guess.
CakePHP has an Ajax helper that does something similar to the Ajax-related helper methods in Rails, so yes, in some way, it's also true.
But CakePHP is really an exercise in futility: its authors wrote it so they wouldn't have to learn Ruby, even though learning Ruby and Rails together is probably easier than figuring out the monstrous mess that is CakePHP.
(This, coming from somebody who does CakePHP at his day job.)
Since y'all asked, my biggest complaint about CakePHP is how it manages to totally butcher the conveniences of object-oriented programming: sure, it implements the Active Record pattern just as much as Rails does, but it makes you pass around data structures.
I feel like any logical person would implement an ORM using faulting and dynamic loading of properties in to objects, which is exactly what ActiveRecord (the Rails library) does. The whole idea of setting a member variable called $recursive to determine which relationships to load is just plain flawed.
Being based on PHP is pretty fatal, too; you can't do anything with global state, you have to depend on mod_rewrite, you pay the startup penalty on every request. Sure, there's optimizations for any environment you're using, but still. People say Ruby is slow, but my own Rails apps run faster than their CakePHP equivalents, last I checked. I admit to being without data on this.
Worst of all, the bugs in CakePHP just about kill it for me. I could tell any number of stories about
the time we spent two days figuring out why CakePHP refused to connect to the right database host
the time half of our pages went blank because of the memory ceiling from using too many components
the amount of code that lives in our AppController because every component load costs several megabytes of memory
the black art of massaging data structures to make XML output work correctly
how we traced down the blank <javascript> tag that shows up at the end of every page
Cake is laid out much like Rails and obviously takes a lot of inspiration & ideas from it. Cake is a nice introduction to MVC frameworks and rails seems pretty straightforward coming from cake experience.
Ajax is super easy with Cake using the JS helper. In fact everything is super easy. Its a great framework, especially for distributed apps (eg cms's) or any other situation where the ease of hosting a php app is a benefit.
I would see the main advantages of rails being Ruby (and therefore the better OO implementation of rails etc) and the community. Gems (much fewer / less comprehensive cake plugins), training materials online, books (eloquent ruby anyone?) meetup groups etc.
I haven't worked with CakePHP, but my impression of it isn't too good. If you're after a Railslike framework for PHP, I think you may be better off looking into Symfony. It's probably a bit more complicated to get started with, but the whole project seems much better organised than CakePHP.
Of course, take with a grain of salt, since these things are quite subjective.