1. Download và cài đặt CakePhp 1.2x

2. Download Prototype

3. Cấu hình cho Json

3. Một ví dụ đơn giản.

To be continous ...

The goal of this tutorial is to setup a working application, which is going to have: user registration, login/logout functionality, user homepage, basic access control, data (form) validation and a flexible base to expand upon. Oh yeah, we'll get all that done in just under 15 minutes and with only about 120 lines of code...

I assume that at this point you've got CakePHP installed and working. It would also be helpful to know the basic concepts and possibly have tried the blog tutorial.

The steps I take to build the app may not be very intuitive for a beginner, but I do provide explanations of each feature/step and hopefully at the end you'll see how everything comes together.

Let's begin...

We need a users table in our database to hold the User data, here's a sample for MySQL:

[sourcecode language="sql"]
CREATE TABLE IF NOT EXISTS `users` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(200) NOT NULL,
`email` varchar(200) NOT NULL,
`username` varchar(200) NOT NULL,
`password` varchar(200) NOT NULL,
`status` tinyint(1) NOT NULL default '1',
`company_id` int(11) NOT NULL,
`created` datetime NOT NULL,
`modified` datetime NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
[/sourcecode]

Next, we'll create a system-wide controller, otherwise known as App Controller. Think of it as a global controller, whose properties and methods are accessible to all other controllers of the application.

Go into your main app directory (something like /home/teknoid/cake/app) and create a file named app_controller.php there.

app_controller.php
This is what it should look like:

[sourcecode language="html"]
class AppController extends Controller {
var $components = array('Auth');

function beforeFilter() {
$this->Auth->allow('display');
$this->Auth->loginRedirect = array('controller'=>'users', 'action'=>'index');
}
}
[/sourcecode]

Let's take a look at what we did here...
We know that our app is going to need user authentication, therefore we include CakePHP's built-in component with var $components = array('Auth');
We then create a special function beforeFilter(), which is going to be executed before all other actions in our application, so this is a pretty good time to tell the Auth component about some things (settings) that it should be aware of.
For example, we allow a special action called 'display' $this->Auth->allow('display') and we also tell the Auth component that, by default, upon login a user should be redirected to the 'index' action (or their homepage) $this->Auth->loginRedirect = array('controller'=>'users', 'action'=>'index');.
I do not want to go into much detail about the specifics of this setup, but overall this is a pretty basic and generic way to set-up the authentication in a CakePHP application.

Next, we are going to build our Users Controller.
Go into app/controllers and create a file named users_controller.php

users_controller.php
This is what it should look like:

[sourcecode language="html"]
class UsersController extends AppController {

var $name = 'Users';
var $helpers = array('Time');

function beforeFilter() {
parent::beforeFilter();

if($this->action == 'add') {
$this->Auth->authenticate = $this->User;
}

$this->Auth->allow('add');
}

function index() {
$this->set('user', $this->User->find('first',
array(
'conditions'=>array(
'User.id'=>$this->Auth->user('id')))));
}

function add() {
if(!empty($this->data)) {
$this->User->save($this->data);
}
}

function login() {

}

function logout() {
$this->redirect($this->Auth->logout());
}

}
[/sourcecode]

Here's what we did...
We've included the built-in Time Helper var $helpers = array('Time');, which basically helps to format (into something human readable) the date and time fields from the database... amongst other things. Later we'll use it to format the date/time information on our user's homepage.

You've noticed that we have another beforeFilter() function as we did in the App Controller. In this example we inherit our parent (App Controller) functionality by using parent::beforeFilter() and then we specify some additional settings for Auth that will be specific to the Users Controller.

Before we procede, I'd like to point out that Auth component will automatically hash your passwords with sha1() + a security salt you've setup during configuration/installation of CakePHP. Be sure to make the password column in your DB long enough to account for the hashed value (plain text passwords will not be stored).

This line $this->Auth->authenticate = $this->User; might be a little unusual...
The quick explanation, as to why I did that, is because Auth component allows us to override the way it handles some things, which offers great flexibility. Personally, I had a little beef with the way Auth handles password hashing, but as you can see it only bothered me during the 'add' action if($this->action == 'add'), in which case I provided my own authentication object (the User model). This is going to become a lot more clear later on (just keep it in mind for now).

To keep things secure from the get-go, we have to be very explicit about what actions we allow the user to access without having to login first. By default Auth is going to redirect the user to the login form regardless of what page one tries to access. Of course it would be really sad for the user, if we didn't tell Auth that 'add' action can be accessed without login $this->Auth->allow('add');.
It is important to point out that Auth will assume that 'login' and 'logout' are always accessible and you shouldn't specify those in the list of allowed actions.

Alright, our basic setup is complete and now we've added some actions into our Users Controller.

index() This is going to be our user's homepage. Remember how we told Auth that upon login the user should be redirected $this->Auth->loginRedirect = array('controller'=>'users', 'action'=>'index');? Well, now we've actually got that part taken care of. The action is really simple, it finds all the information about our logged in user and sets it ready for the view.

add() No mystery here, this is our user registration action and it should be quite obvious as to what it does.

login() It is this easy to get the basic login functionality working... i.e. you don't even need to write any code. Auth is smart enough to do the work for you. Of course you can easily change the way Auth does things by extending this action beyond the basics.

logout() Once the user clicks a "Log out" link he/she will be redirected to the default location, which happens to be back to the login form. Good enough for this example.

Now that we've got some of our actions finished up, let's create the views for each one (a view is the actual page that the user is going to see in the browser).

Go to app/views/ and create a directory named 'users'. Then in that directory add a view file for each of the actions (except logout, since it doesn't need one).

index.ctp - our homepage
[sourcecode language="php"]
link('Log out', array('controller'=>'users', 'action'=>'logout')); ?>

[/sourcecode]

This is a very simple view page, but it does show how you can access the various user information in the view. If you look back to our index() action in the Users Controller, you'll see that we set a $user variable, which contains an array of user data and now we can echo it in the view.
Remember that Time Helper we've included earlier in our Users Controller? Well, here we're using it to transform our database DATETIME field's value, into a nice, human readable output by using: echo $time->niceShort($user['User']['created']);

login.ctp - our login page
[sourcecode language="php"]
if ($session->check('Message.auth')) $session->flash('auth');
echo $form->create('User', array('action' => 'login'));
echo $form->input('username');
echo $form->input('password');
echo $form->end('Login');

[/sourcecode]

Even though we don't need any code for the login() action we still need to setup a basic form to display to the user. Nothing fascinating here, just note that first line if ($session->check('Message.auth')) $session->flash('auth');, which allows us to display any messages triggered by the Auth component.

add.ctp - our registration page
[sourcecode language="php"]
echo $form->create();
echo $form->input('name');
echo $form->input('email');
echo $form->input('username');
echo $form->input('password');
echo $form->input('password_confirm', array('type'=>'password'));
echo $form->end('Register');
[/sourcecode]

Here we have setup a basic form for the registration. Again there is really nothing fancy here... just a basic form, which will be brilliantly built by the Form Helper.

If you haven't tried already, go ahead now:

Try to access http://yourlocalhost/users/shouldntAccessThis
- Auth component should redirect you to the login form, since we've never specified that 'shouldntAccessThis' is allowed.

Try to access http://yourlocalhost/users/add
- You should see a registration form

So far so good, but we've got to setup some validation rules for our registration form...
For this we create our User Model.

In app/models/ create the file user.php

user.php
This is what it should look like:

[sourcecode language="html"]
class User extends AppModel {

var $name = 'User';

var $validate = array(
'name'=>array(
'rule'=>array('minLength', 4),
'message'=>'Name has to be at least four characters'),

'email'=>array(
'rule'=>array('email'),
'message'=>'Please enter a valid email'),

'username'=>array(
'Username has to be at least four characters'=>array(
'rule'=>array('minLength', 4)
),
'This username is already taken, please try another'=>array(
'rule'=>'isUnique'
)),

'password'=>array(
'Password cannot be empty'=>array(
'rule'=>array('notEmpty')
),
'Password must be at least four characters'=>array(
'rule'=>array('minLength', 4)
),
'Passwords must match'=>array(
'rule'=>array('passwordCompare', 'password_confirm')
))
);

function passwordCompare($data, $fieldTwo) {

if($data['password'] != $this->data[$this->alias][$fieldTwo]) {
$this->invalidate($fieldTwo, 'Passwords must match');
return false;
}

return true;
}

function hashPasswords($data, $enforce=false) {

if($enforce && isset($this->data[$this->alias]['password'])) {
if(!empty($this->data[$this->alias]['password'])) {
$this->data[$this->alias]['password'] = Security::hash($this->data[$this->alias]['password'], null, true);
}
}

return $data;
}

function beforeSave() {
$this->hashPasswords(null, true);

return true;
}
}
[/sourcecode]

So this is the big guy. The User Model handles our validation logic and also overrides some of the default Auth component functionality. Remember how I said that we'll use the User model to override default Auth behavior $this->Auth->authenticate = $this->User; during the 'add' action? Well here I have built my own hashPasswords() method, which overrides the Auth component's default one. Without going into a long winded explanation I'll just say that I prefer to hash the passwords just before saving the data (hence the little beforeSave() method) because it makes my life easier, and it also shows how easily Auth can be extended to behave the way you want it to.

Let's take a look at passwordCompare(). This is my custom validation method to compare 'password' and 'password_confirm' fields (look back to our add.ctp view).
$this->invalidate($fieldTwo, 'Passwords must match'); will cause the 'password_confirm' field to be marked as invalid in addition to the 'password' field. This is nice if you've got some CSS that, perhaps, puts a red border on the input box for the invalid field (notice that we've also set the error message).
Another trick (I'm not quite sure honestly if it's a documented feature) is to use really nice, human readable names for a given rule. This is in case you use multiple rules per field as we do for our 'password' field. This way, in case of an error, the arbitrary rule name will be used for the error message.

Go ahead, try it out with some invalid and then valid data... If all goes well, you should see an SQL debug showing the inserted user data, which confirms that your form is working correctly.

And there you have it... A complete, functional app in about 10-12 minutes.

Therefore if you attempt to save some value other than 0 or 1, CakePHP will not allow you to do that (instead it will just save 1). The easiest way to get around this is to make your field tinyint(2), as one option.

FYI, supporting ticket: https://trac.cakephp.org/ticket/3903

Một hướng phát triển trong thời gian đây mà tôi quan tâm đến, khá theo định hướng của ông lớn Google, mô hình hệ thống phân tán dịch vụ đa thành phần. Tôi tạm đặt tên là như vậy. Ajax là một công nghệ, kết hợp với mô hình trên quả thực là thành bộ đôi không gì tốt hơn. Trước đây, khi định dạng dữ liệu XML giữa client-server và ngược lại được những người phát triển Ajax sử dụng rất phổ biến, nhưng từ khi xuất hiện Json, XML dần trở thành dĩ vãng bới thua kém về sự nhanh-gọn-rẻ trong sử dụng. Và từ khi Prototype hỗ trợ Json, tôi thậm chí còn không còn nghĩ đến XML nữa. Công nghệ thật thay đổi nhanh chóng.

Thật là may mắn, qua mấy buổi cafe với bạn, google tài liệu và cả đống sách tính bằng GB trong máy, mô hình phân tán dịch vụ đa thành phần là cốt lõi, là định hướng; CakePHP, Json và Prototype là những công cụ để tôi xây dựng hệ thống cho các sản phẩm sắp tới của mình. Tôi sẽ có những bài báo chi tiết hơn cách xây dựng, cấu hình hệ thống để những công cụ này làm việc với nhau thật hiệu quả và áp dụng mô hình hệ thống phân tán dịch vụ đa thành phần vào xây dựng hệ thống của riêng bạn như thế nào !!! Hãy đón đọc trong các kì sau

To be continuous ...

To follow the tutorial,you need the following software and resources.
1.Netbeans IDE ver 6.5- PHP module
2.JDK version 6 or 5
3.MySQL version 5.0
4.Xampplite
5.CakePHP

Setting up the resources downloaded
Install all the executables except CakePHP.
For more information on how to set up netbeans visit (www.netbeans.org)

Creating a PHP project with the IDE

1.Select File>New Project... ,PHP >PHP Application

Click Next.
2. Set the
Project name : Organiser
Change project location to where ever

Click Next
3.Run Configuration:
Set -:
Run As: Local Web Site (running on local web server)
Check :Copy files from Sources Folder to another location.
Copy to Folder : browse to the location of xampp installation and select "htdocs" folder

Click Finish.

Setting the project up
Unzip the cake_1.2.0.7692-rc3.zip
Copy all the files in the unzip file to your project_directory/web

This is the structure for most application.
The project will be as shown:

Setting up the database for the project
In the IDE,under Source Files select file "database.php.default" as shown

Rename the file to "database.php".
Now edit the database.php file as shown

This is the settings i used, change to reflect yours. (login ,password ,database,host).

Codes in the application
All the php source files will be placed in the structure as shown above.
Take a moment and look at the struture under /app (models, views, controllers => MVC design pattern)
All the models of the application will be placed under /app/models
All the views of the application will be placed under /app/views
All the controllers of the application will be placed under /app/controllers

Lets have the first cake:
Scripting the models:

The figure shows us the models we need to create.

Under Source Files>app/models, Right click and then select New> PHP file..
Set the filename: task
Check if the Folder is set to "web/app/models"
Edit the file to reflect as shown:

NB: CakePHP has a convention used to bake the application based on the filename and class name of the models.You must follow the naming as i have done to make it work.Go to http://www.cakephp.org for more information on the conventions.

Create the other three models as we did above.
Edit appointment.php to reflect

Edit note.php to reflect as shown below

Edit contact.php to reflect as shown below

What just happened?
We just created four models to reflect our tables in the database.
Each model inherits from AppModel.This is a class from CakePHP to help model the tables.
Since we are following the conventions, CakePHP will get all the attributes from the tables for each model for us.

Scripting the controllers:
Every model needs a controller and the basic CRUD will be generated at runtime for us via CakePHP scaffolds.

Under Source Files>app>controllers, Right click and select New>PHP file..
Set the filename: notes_controller
Make sure that the folder is set to web/app/controllers
Edit the file to reflect as shown below.

Create the other three controllers with filenames(contacts_controller, notes_controller, appointments_controller).
Edit the contacts_controller.php file to reflect as shown below

Edit the appointments_controller.php file to reflect as shown below

Edit the tasks_controller.php file to reflect as shown below

What just happened?
We just created four controllers to manage and control our models.Open any of the controller files
,you realise there are no methods.You only see two variables.
var $name='Appointments' for the appointment controller.
var $scaffold;
The variable declare above does the trick. This informs CakePHP that we want a basic CRUD operation and so should take care of it for us.
What CakePHP does is to bake a read, create, update, and delete operation for all the models that have the variable $scaffold declare.What we get is a well bake cake ready to be eaten.

Testing
Open your browser and Enter this url : http:localhost/Organiser/contacts

You will notice that the page has "CakePHP : The rapis application development" header.

Adding a home page for the application
Create an empty file with filename home.ctp into app/views/pages.That is where pages without controllers are kept.
Edit to as show below:

Changng the default layout
Create an empty file with filename default.ctp into app/views/layouts.
Edit the file to reflect:

Add a css to help in laying out the pages well.
Get the file stylesheet and create a css file with name stylesheet into folder /app/webroot/css.

Running the final project
After all this alteration the final page.

Summary

We just created a simple organiser in a short time.

Thankfully the answer is pretty simple, just make sure that the session (cookie) name is the same for both apps.
In CakePHP it's set in the core.php... Configure::write('Session.cookie', 'CAKEPHP');

Consider the following example:

[sourcecode language="php"]
function afterFind($results, $primary=false) {
if($primary == true) {
foreach($results as $key => $value) {
$results[$key][$this->alias]['my_field'] = $this->modifyField($value[$this->alias]['my_field']);
}
}

return $results;
}
[/sourcecode]

While this works just fine for most cases, the main issue is that $value in the above example is actually a copy of the array's content.

In PHP5 we have the option to reference the array elements of $results, by using: "$results as &$value".

So the modified code for PHP5 would look like:

[sourcecode language="php"]
function afterFind($results, $primary=false) {
if($primary == true) {
foreach($results as &$value) {
$value[$this->alias]['my_field'] = $this->modifyField($value[$this->alias]['my_field']);
}
}
unset($value);

return $results;
}
[/sourcecode]

The obvious improvement is that we are not creating any extra copies of our data. Sure, it may not cause any serious issues, but if making additional copies of the data can be easily avoided it probably should be. Secondly, it makes the code cleaner and more concise, which is always a good thing.

P.S. It is always a good idea to unset() the reference in case any further processing might accidentally change the value of our $results array.

One might ask what's the point of using 'id' and 'name'? Well, the 'name' key allows you to change the file name as it will be displayed to the user (in a "save" dialog, for example), it is not the actual name of the file on the server or at least it doesn't have to be. For example, if you have a reporting tool that generates some files and their name on the server happens to be 329569364658875.zip, you can modify such ugly name on the fly by specifying 'name' => 'user_friendly_file_name'.

Also, remember that 'path' is relative to your app directory and requires a trailing DS (directory separator). Therefore if you have a path like /home/bob/cake/app/files_for_download, you specify:
'path'=>'files_for_download'.DS

And just to reiterate what the manual says, media views allow you to perform authentication before delivering content and you can deliver files which are not accessible from webroot to prevent direct linking.

P.S. Thanks to skiedr and Tarique Sani who've pointed out that you can now cache the files generated by media views, which ultimately means that images, etc. can be fetched from the browser cache if available.

Among some of my initial stumbling blocks has been working through the idea of access control from the framework viewpoint. I "get it" when it comes to writing my own code, like in the revealCMS, and I "get it" in the context of certain "things" (usually users) needing access to specific things (often controllers and actions). The hard part is sorting out where to even start with all the alphabet soup: Auth, Acl, Aro, Aco, etc etc etc. How do you even get to a point where you have a simple working prototype to expand on?

Apparently there are numerous examples and tutorials of how to get started with Cake Acl, however I find many of them to be over-complicated or thorough. In other cases some are simply too terse. There is a fine line between terseness and conciseness. Even the CakePHP docs leave much to be desired for newer users: the official Acl documentation is long and kind-of confusing, and the sample application tutorial (also part of the official docs) seems to do things differently than explained in the primary documentation - a considerable problem, in my opinion. Yes, I do realize that the concept of Acl really depends on your application, but shouldn't documentation at least be consistent? The one saving grace, however, is that the Bakery has a few examples, which brings me to my next point.

I found a tutorial I actually like so far. By "so far," I mean I haven't finished it yet, but to this point I've gotten more done than most articles have gotten me in just setting up the Acl... and it's not all that difficult. It's Ketan's How to use Acl with Cake PHP 1.2.x?* No dobut some of you will stumble across this post here, and hopefully find it useful. I think once the dust settles on the first step, you(we) will be able to look at some of the other tutorials and adapt them to our own specific needs.

I'll try to keep this post updated with additonal solutions as I find them.

* There ARE some typos in the example code, so be aware of that and make modifications as necessary.

For the sake of example let's do something simplistic, like:

[sourcecode language="php"]
pr($this->Company->find('all', array('fields'=>array('Company.id','Company.name', 'COUNT(id) AS total_count'),
'group'=>array('Company.name'),
'recursive'=>-1)));
[/sourcecode]

This is all fine and well, except our total_count field does not appear with the rest of the fields in the resulting data array, but rather in it's own index, like here:

[sourcecode language="php"]
Array
(
[0] => Array
(
[Company] => Array
(
[id] => 1
[name] => New Company
)

[0] => Array
(
[total_count] => 1
)

)
[/sourcecode]

We can use Set::check() and easily reformat our array in afterFind(), so that we can reference all fields in a consistent manner.

Try something like this in your model (or app model):

[sourcecode language="php"]
function afterFind($results, $primary=false) {
if($primary == true) {
if(Set::check($results, '0.0')) {
$fieldName = key($results[0][0]);
foreach($results as $key=>$value) {
$results[$key][$this->alias][$fieldName] = $value[0][$fieldName];
unset($results[$key][0]);
}
}
}

return $results;
}
[/sourcecode]

Now all fields appear where we would expect them.
Referencing all fields in a consistent manner (in the view, for example) is already a good enough benefit to use an approach similar to this one, but in addition if the change is ever made to the core in order to fix this up, your code will not be affected in any way.

Last fall I was working on a niche-oriented CMS and was getting majorly bored/burned out by all the procedural stuff; the code felt horribly messy to me and I wanted to get into OOP (Object Oriented Programming) but previous attempts had left me scratching my head.

Somehow I stumbled on CodeIgniter and I was immediately hooked. Once I figured out my way around MVC and their way of doing things I tripled the amount of code I was able to put out. Was my code the best you could ever find? No, but it was definitely a step ahead of where I'd been.

Once I finished the CMS I decided to tackle another project and turned again to CI. I've been working on this project for the majority of 2008, and might have it done by the end of the year.

Now, I really love CI because it's so easy and flexible, and it's pretty much agreed that they have the easiest to understand documentation. However, I began to get frustrated with some of the features the default CI lacks - Auth being the biggest -- so I started "shopping around" some other popular frameworks. Following are the ones I dabbled with. Note that there are no benchmarks because frankly that wasn't my concern -- realtive ease of use and the speeding up of my development were the primary concerns was.

Zend Framework - http://framework.zend.com:
Impression: After Symfony, I say ZF is probably the daddy of the frameworks. You can develop some really powerful stuff with it. That said, I found it to have a really steep learning curve and to be too loosely coupled for my taste. Requires more manual configuration than most other frameworks. It took me almost a full day to figure out the Zend_Db class and even then I wasn't able to move too far with it. I was really impressed with their ACL and Auth classes, although I didn't get far enough to really dabble with them.
Conclusion: If I had more time to play with it, I'm sure I could figure ZF out and develop some really cool stuff. For now, I will most likely stick with implementing components of ZF with other frameworks.

CakePHP - http://www.cakephp.org
Impression: One of the most popular frameworks. Pretty strict with naming conventions. Models are a must (this is not a bad thing). I actually played with this for a couple of days and got a lot farther with it than I did with ZF. The docs (2.2) are pretty good and I was able to find almost everything I needed to know within them. Because it's so popular, finding things that weren't in the docs -- like a form tutorial -- was really easy.

Conclusion: I may go back and try my hand developing something with Cake. If you have moderate experience with MVC, it's not (IMO) that hard to learn. It's a lot slower than pretty much any other framework but it also does a lot of stuff for you that could speed up your production.

KohanaPHP - http://www.kohanaphp.com
Impression: Kohana is a relative newcomer to the PHP Framework scene; it originated as a fork of CI when a bunch of CI developers got tired of waiting for EllisLab (creators of CI) to fix bugs with CI. Right now the current release is 2.2 (I think) and while a lot of things are different from CI, it's still feasible to port CI apps to Kohana by renaming a few things and following some different rules, like using helper::helper_function instead of $this->load->helper('helper') and helper_function(). I wasn't very impressed with their docs; I found reference to the "Forge" class, that helps consolidate form creating/validation rules, only to find out Forge has been depreceated in Kohana 2.2.
However, Kohana does seem very powerful and I don't think it would be too big of a leap to go from CI to Kohana. I really like that they have an advanced archive class as well as auth and payment modules.

Conclusion: I will probably use Kohana at some point; I may even recode the 2nd draft of my current project in Kohana since it provides more built-in functionality than CI does. I really like that it is community based; however, from what I've read the framework seems to depreceate things fairly often, which could make developing with it a pain in the ass.

CodeIgniter - http://www.codeigniter.com
Impression: As I said, I love CI. It was so easy to learn and really helped speed up my PHP production. The community is awesome, the docs are awesome, and it's so flexible I can do pretty much anything I want with it. The "bare-bones-ness" of it, though, is also frustrating at times, especially when I have to manually code something in that the other frameworks provide by default -- again, mainly Auth stuff. I think it's kind of neat that it's used and backed by a company (EllisLab, which produces the Expression Engine commercial CMS), which should provide security as far as it being around. The bad thing about that is that since it's developed and maintained by a company, fixes to bugs and other issues can take a lot longer than a community driven framework. I'd really like to see CI get into module-type stuff or at least include company-supported libraries like auth and payment.

Conclusion: I will likely stay with CI for now; when I get more time to dabble with Kohana more it will become more of a competition in my mind. I have to say, though, that for each (hee!) framework I tried, I ended up going back to CI with relief mostly for its flexibility. That could just be due to my being most familiar with CI, though.

To wrap it up, my choices would likely go like so:

1. CodeIgniter
2. Kohana
3. CakePHP
4. Zend Framework

I know that this hasn't been a very "techy" type of comparison; as the title suggests, these are merely my opinions on the 4 frameworks I've tried out. Eveyrone has one that clicks for them, and you're definitely entitled to use that one and call it the best (for you!).

I tried CakePHP but it was a little too rigid on its rules when it came to the data access layer, not enough flexibility. I don't like frameworks that box you in trying to get you to do things a certain way. I want a certain amount of freedom when I code. I've been reading lately about CodeIgniter which is a very lightweight MVC framework that gives you that freedom (from what I've read). So I will be trying it in the next couple of weeks.

I think that in the long run I'd like to be able to make Drupal modules and build applications on it. Besides, there is a crazy amount of people out there using Drupal for their portals, ecommerce, and other sites. All of those will need maintenance at some point and I will be ready to dive in if I ever get a contract like that. But if I ever want to write something from scratch I am going to use a framework like CodeIgniter. That way I have the best of both worlds.

I will update the blog as I learn more about both platforms...

I've seen this question float around here and there, but do not recall any specific solutions...

So here, I propose one method which requires a temporary hasMany bind between the model which we are saving and the join table model, then using saveAll() to save the data.

Let's take a look at an example, where we have the good ol' Post HABTM Tag.

We are trying to save a new Post, for which we already know a Tag.id (a pretty standard HABTM save scenario), but now we also need to save an extra field 'status' into our join table.

[sourcecode language="php"]
$this->data['PostsTag'][0]['tag_id'] = 15;
$this->data['PostsTag'][0]['status'] = 'disabled';

$this->Post->bindModel(array('hasMany'=>array('PostsTag')));
$this->Post->saveAll($this->data);
[/sourcecode]

And that's all there is to it, we've now saved our Post as well as our relation to Tag and the required extra field. Of course, in reality, your data will come from the form, but hopefully you get the gist of this idea.

You might have noticed some examples where you have:

[sourcecode language="php"]
$this->Profile->find('all', array('fields'=>array('SUM(Profile.votes) AS total_votes')));
[/sourcecode]

But what if you simply needed Profile.field AS another_name?
'fields'=>array('Profile.field AS another_name') ... isn't going to work, just like that.

What you need to do is escape the fields in your 'fields' array, like so:

[sourcecode language="php"]
$this->Profile->find('all', array('fields'=>array('`Profile`.`name` AS `another_name`')));
[/sourcecode]

(Note the backticks)

$this->Auth->user()

Logging events

$this->log('==>bla bla<==',LOG_DEBUG);

[sourcecode language="php"]

if($this->User->save($this->data)) {
$this->Session->setFlash(... some stuff for the view ... );
$this->redirect(array('action'=>'success'));
}
[/sourcecode]

If all we are doing is displaying a "success" page back to the user, do we really need to bother with a redirect()?

To me it seems a little easier to do:

[sourcecode language="php"]

if($this->User->save($this->data)) {
$this->set('arrayOfMessages', $myPreviouslyPreparedArrayOfMessages);
$this->render('success');
}

[/sourcecode]

Not really a big deal one way or another, but something to consider (especially for those very high traffic servers ;)).

P.S. As some readers pointed out, the obvious draw back is that $this->render() will cause the data re-submit prompts when refreshing or going back in the browser.

Let's say we've defined some basic validation rules in our Profile model, something like:

[sourcecode language="php"]
var $validate = array (
'name' => array(
'rule' => array('notEmpty'),
'required' => false,
'message' => 'Please enter a name'
)

.... and so on for all other fields ...

);
[/sourcecode]

Now we've got an action where this particular set of rules isn't going to fly...

Maybe the data is coming from an external (somewhat untrusted) source and in this case we need to make sure that the 'name' is present in the data array (i.e. 'required'=>true) and that it's not only 'notEmpty', but now it has to be 'alphaNumeric'.

So we do an easy "update" to our default rules, which we've previously defined in the model:

[sourcecode language="php"]

$this->Profile->validate = Set::merge($this->Profile->validate, array(
'name'=>array(
'required'=>true,
'rule'=>array('alphaNumeric')
)
));

[/sourcecode]

What happened is that now all our default rules remain as we have defined them in the model, but the 'name' field is now going to be validated using this new set of rules.

The theory is that you set your $validate array with some default rules that will apply in most of the situations, and use this technique when your validation rules have to change for a few fields in any given action.

To make things even cleaner you should probably add a method to AppModel called something like modifyValidate, and then you could use:

$this->Profile->modifyValidate(... array of new rules...);

Kumbia es un web framework libre escrito en PHP5. Basado en las mejores prácticas de desarrollo web, usado en software comercial y educativo, Kumbia fomenta la velocidad y eficiencia en la creación y mantenimiento de aplicaciones web, reemplazando tareas de codificación repetitivas por poder, control y placer.

Sus principales características son:

• Sistema de Plantillas sencillo
• Administración de Cache
• Scaffolding Avanzado
• Modelo de Objetos y Separación MVC
• Soporte para AJAX
• Generación de Formularios
• Componentes Gráficos
• Seguridad

y muchas cosas más.

Adicional a esto Kumbia integra lo mejor de la Web en un solo framework para producir las aplicaciones Web del mañana (prototypejs, phpMailer, Smarty, FPDF, Script.aculo.us)

Kumbia puede ser la solución que estabas esperando!

Lo mas importante de todo es que Kumbia está 100% en español, recomendado para proyectos medianos o grandes, preferentemente que lleven mas de 10 páginas dinámicas

Sitio web Kumbia

Overhead means maintainability

Everytime you can use php to spit your html, do it.
You'll face performance issues with the overhead, but
will gain with the no open-close of php process tags.

<?php
echo $html->link('index', array('action' => 'index'), array(
	'class' => 'icon'
	,'id' => 'index-button'
	,'rel' => 'content index'
));
echo $html->link('quit', array('action' => 'logout'), array(
	'class' => 'icon'
	,'id' => 'logout-button'
));
?>

Echo usage

Php's echo, as any other function, causes overhead and slows your app down
every time you use it - read "it let's my app more beautiful", I don't care about overhead,
so, only one call per block:

<?php echo
$html->link('index', array('action' => 'index'), array(
	'class' => 'icon'
	,'id' => 'index-button'
	,'rel' => 'content index'
))
,$html->link('quit', array('action' => 'logout'), array(
	'class' => 'icon'
	,'id' => 'logout-button'
));
?>

Noticed the comma? echo will print every passed arg,
so no need for concatenation. That's the next topic.

No concatenation

I don't like it and I'll try hard not to use it. I prefer working with joins and arrays
than concatenating words, it's cleaner, it's beatiful. - my blog, my opinion.

<?php echo
$html->link($fooAction, array('action' => $fooAction), array(
	'class' => join(' ', array($fooAction, $markerType, 'custom-link'))
	,'id' => $fooAction . '-marker'
))
?>

For the wonderers: why not to use doulbe-quotes? read next.

No var on strings

It's all about performance. No it's not. It does increases performance, it's
true, but it's not what bothers me. Vars on strings are not readable, not every
IDE recognizes them, and ... they are somewhat ugly.

There are various ways to suppress them, the join-array show above is one,
but the way I'm more likely to use is using sprintf(),
because I really think it's more readable and maintainable:

<?php echo
sprintf('%s says: %s. from %s. in %s', $person, $comment, $device, $date)
?>

Stick to the core

All and all, you're using the framework for your freaking awesome app
because, knowing or not, you do trust people who codes it. They probably
code better than you, and better than people who's using their code.

So, using an auth plugin? pimping your own solution for already known
issues or work's forme? grabbing 'fourth' party code to handle your XML?

No. Stick to the core. You'll be dealing with full-featured code, supported
standards, community friendly solutions, revised and maintained issues and
hardcore coders work.

Inheritance is your friend

Asked for a feature and framework devs denied, or are too busy with
bugs, or are just not having enough time? Wanting a easier way of
accomplish tasks your app need?

Stop crying and abuse of inheritance. Extend everything you think
doesn't fit your app needings.

- A side note for the ones that plan to follow this: Keep in mind that changing class' methods context,
usage and behavior are not SO "good design" as it CAN mess with your code
readability.

App::import('Component', 'Email');
class AppEmailComponent extends EmailComponent {
	function addReceivers($receivers, $type = 'cc') {
		[... your nifty code ...]
	}

	function attach($file, $alias = null) {
		[... your nifty code ...]
	}

	function send($content = null, $template = null, $layout = null) {
	    if($content === true) {
	        [... do stuff ...]
	    }

	    return parent::send($content, $template, $layout);
	}
}

It's not yours, it belongs to the App

No MyHelper, MyHtml, MyForm... it's not yours, not mine, not PL's or Bosse's.
It belongs to the App.
So always when extending a core class, the suffix is "App".

App::import('Helper', 'Form');
class AppFormHelper extends FormHelper {
    [... my nifty code ...]
}

As you can see, I don't mind overhead and little performance hits if
the end code will be more readable and mantainable - and beautiful.
That's what you get when working in large projects, with no lifetime
expectation: you need to have a code that talks by itself and that can be
easily changed by every new guy assigned to work with it.

That's it for now, I'll try to keep posting regularly till the
end of this series about the view layer and how can you get more donuts
out of it - as my project does.

hum... feedback on my code standards are welcome. And don't forget to
catch on my typos!

The biggest drawbacks to this approach are that CakePHP does not intrinsically allow the develop to take fields from the database and convert them to a Flex front-end model.  In order to force CakePHP to comply, there is an extra layer that has to be forced into the framework in an unnatural way.  Normally, this hasn't been a big deal when working with back-end Java solutions as object modeling straight out of the database is a common practice (although Hibernate may have similar problems as CakePHP).  With my background in Java, and my lack of CakePHP understanding, I find it difficult to understand where the CakePHP devs are coming from. 

There are many other benefits as well as drawbacks to modeling on the back-end in a CakePHP environment that have been carefully outlined in Aaron Hardy's blog post entitled: The Why, What, and Where of Custom AMF Class Adapters.  I have made a few comments as well as some of the other developers at MediaRAIN.  Here are some of the key points from this awesome article:

Pros

• lack of high coupling
• less of a chance of refactoring due to database schema changes
• Decreases SWF size due to an absense of Adapter classes on the front-end
• Reduces the need to recompile the SWF due to back-end changes (especially handy in AIR when updates need to be sent out).
• Utilizes more of the server's juice than the client's computer (could also be a con depending on the circumstance, but I feel that in the majority of circumstances you can choose to upgrade your server speed, but you are at the mercy of the client's computer speed.)
• Maintains the Flex front-end coding conventions and styles (i.e. first_name in PHP, firstName in Flex)
• Maintains the Flex standard of server communication: the Data Transfer Object pattern
• You can take advantage of AMF's object mapping abilities to automatically cast the correct Data Transfer Object in PHP to it's Flex equivalent without traversing Object hierarchys or Arrays.

Cons

• Back-end dev may need to twist the arm of the CakePHP (or Hibernate) framework to get it to include a back-end class adapter.
• By adapting classes on the front-end, a single back-end API can have the ability to serve multiple front-end clients due to its abstract nature, as opposed to a back-end closely tied to one particular front-end implementation.

In short, my feeling is that Data Transfer Objects should be implemented on the server-side and that any departure from this methodology should be the exception rather than the rule. There is a reason why Adobe supports it and why it is used in Cairngorm, Nimbus, PureMVC, and other Flex frameworks and by countless Flex developers throughout the world. Keeping in mind that every good answer seems to involve the words "It depends", I am forced to not give a concise simple answer, because it really does depend on your implementation.

I'm sure there are plenty of other pros and cons that I am missing, or if anyone would like to comment on this discussion, please do!

App::Import ('model', 'User');
class Seller extends User {

var $name = 'Seller';

}

Thanks to Przemysław Sitek for this useful snippet!