Part 1 of this series lays out the scope for the series, introduces the frameworks being examined, covers their installation, and scopes out the first test application you will build.

Part 2 walks you through building the sample application in each of the three frameworks, highlighting their similarities and differences.

Part 3 starts with extending the test application, then deals with exceptions to the rule. All frameworks work well when doing the tasks for which they were designed. Needing to do something the framework wasn’t built to do happens on every project. This article looks at such instances.

Part 4 focuses primarily on Ajax support. The use of Ajax, using native code and third-party libraries, is examined — specifically, how each framework behaves and accepts specific popular libraries.

Part 5 deals with working outside the frameworks. A single task is identified (nightly update script), and the process for accomplishing this task is examined in each framework.

[via guymon]

CakePHP is mostly an advanced MVC framework, with a few extra modules added on top. It can handle most of the database stuff for you, and it includes support for Ajax and data validation. It also has a unique user authentication module called ‘Access Lists’, which can be used to give different users access to different parts of your CakePHP website.

This framework seems quite thorough and ready for use, although the CakePHP website is extremely confusing. There doesn’t seem to be a stable version yet, which is a bit surprising since it’s been in development for months now, but I guess it’s probably possible to use the beta version on a production website as well.

[via Sam's random musings]

I think is all a matter of marketing, CakePHP is the best framework but it’s marketing hasn’t been the best.

* It needs some killer app
* It needs some killer tutorials
* Screencasts would be cool

I agree with that comment. Let us compare CakePHP with two of its “competitors”: symfony and Ruby on Rails (RoR). Both frameworks have one or more killer applications: symfony has askeet and RoR, well, they have several applications. And CakePHP? Hm, there is no such killer application in sight… (maybe someone is developing it in stealth mode, who knows?). symfony has found a nice way to create their killer application, they developed askeet in 24 steps within the scope of an advent calendar. Each step has been created as a tutorial, so they kill two birds with one stone: they have a killer application and a series of tutorials. Genial! What do you think could be the killer application for CakePHP? Or do you have an idea how to create one?

The next point are the killer tutorials, or, more general, the documentation. The good thing is: all three projects provide extensive documentation: manuals, howto’s, tutorials, api documentation. Even though, it is obvious that the documentation is a weakness of CakePHP when compared with the other projects. Well, the most important point is that it is not easy to find the documentation for CakePHP. A page with all available documentation is missing. And on the homepage you only find a link to the wiki (yeah, there are also links to the api and the manual on the homepage, but they are hidden and you find them only by accident). What could we do to improve that weakness of CakePHP?

The last point, screencasts, is a “nice to have” point, at least for me. Nonetheless, all three projects have at least one screencast. symfony and RoR place the link to the screencasts prominently on the homepage, whereas you have to search the screencast for CakePHP. Yes, there exists a CakePHP screencast, but the link to the screencast is hidden in the wiki ;-)

Conclusion: I think CakePHP can keep up technologically with the other projects, but it has to learn to sell itself better :)

CakePHP is very promising, the only problem – really, I don’t know if it is a problem – is: the development process is very slow.

Hm, I cannot say if the development process is slow compared with other frameworks, but what I see is that there is a steady progress. What do you think?

The guys from livepipe asked me for feedback, so I thought I would do their blog tutorial (btw: there exists two blog tutorials for CakePHP beginners: Building a simple blog and Scaffolding a Blog).

I have to admit that I was not able to get the “Hello world” example working, some file (runtime.php) was not found. I do not had the time and the desire to figure out what the problem was. Perhaps it was because I tried to install it in a subdirectory? I do not know…

Ok, so I will write something about livepipe without knowing it, so correct me if I am writing nonsense ;-)

The killer criteria for me against Pipeline is that there is no support for MySQL (or PostgreSQL), the databases I usually use. Only the SQLite database is supported (which has the advantage that you do not have to configure your database settings).

What seems to be very cool is that you do not have to manage your database tables manually because it is done by the framework. The only thing you have to do is to define your model (or ActiveRecord as it is called by Pipeline), everything else (creating table, adding/removing columns) is done by the framework. That is a feature that would be nice to have in CakePHP.

The directory layout is something I do not like. I think it is not practical to have all files of your project in one folder despite the Pipeline naming conventions.

The action/view mapping seems to be cumbersome compared to the solution offered by CakePHP. The same example in Pipeline:

class BlogController extends Controller {
public function __construct($url = false,$parent = false){
$this->addView(‘/’,'index’);
parent::__construct($url,$parent);
}

public function index(){
}
}

and in CakePHP:

class BlogController extends AppController {
public function index(){
}
}

There is not a lot of documentation for Pipeline available yet. That would not be that bad if there is a Pipeline community, but there is nothing: no wiki, no IRC, no mailinglist, nothing (they write on the contact page that there will be a forum in a few weeks, whatever that means).

Conclusion: personally, I would not use the Pipeline framework yet due to a lack of community, and because I think that CakePHP fits my needs better. But Pipeline is in a very early stage, so everything is possible. Good luck, Pipeline developers!