PS: Quite some time ago, I used this for my ContactForm. This is a live example on how to use such a table less model and how validation can still be performed on these virtual fields.

How is it used?

class MySchemaLessModelName extends AppModel {
    protected $_schema = array(
       'status' => array(
           'type' => 'boolean',
           'length' => 1,
           'default' => 0,
           'null' => false,
           'comment' => 'some optional comment'
       ),
       ...
    );
}

By manually describing your table less fields cake you can have the same form helper magic. So the FormHelper will display a checkbox for boolean fields, and textareas for text fields etc. Also you get all the validation (length or required for example) out of the box. You can also set up the $validate array for additional validation, of course.

Full schema reference

Boolean (tinyint 1):

'approved' => array(
    'type' => 'boolean',
    'length' => 1,
    'default' => 0,
    'null' => false,
    'comment' => 'some optional comment'
),

Integer (int 10/11):

'clicks' => array(
    'type' => 'integer',
    'length' => 10,
    'default' => 0,
    'null' => false,
    'comment' => 'some optional comment'
),

String (varchar 1…255):

'subject' => array(
    'type' => 'string',
    'length' => 255,
    'default' => '',
    'null' => false,
    'comment' => 'some optional comment'
),

Text (text):

'comment' => array(
    'type' => 'text',
    'length' => null,
    'default' => '',
    'null' => false,
    'comment' => 'some optional comment'
),

Decimal (float):

'amount' => array(
    'type' => 'float',
    'length' => '6,2',
    'default' => 0.00,
    'null' => false,
    'comment' => 'some optional comment'
),

Foreign key as UUID (char 36):

'user_id' => array(
    'type' => 'string',
    'length' => 36,
    'default' => '',
    'null' => false,
    'comment' => 'some optional comment'
),

Date (date)

'published' => array(
    'type' => 'date',
    'length' => null,
    'default' => null,
    'null' => true,
    'comment' => 'some optional comment'
),

Datetime (datetime)

'modified' => array(
    'type' => 'datetime',
    'length' => null,
    'default' => null,
    'null' => true,
    'comment' => 'some optional comment'
),

Enum (at least my version of it – since cake doesn’t have a core solution here)

'status' => array(
    'type' => 'integer',
    'length' => 2,
    'default' => 0,
    'null' => false,
    'comment' => 'some optional comment'
),

Note: All fields (except for date/datetime) are set to “not null” in the above examples (which will make the form helper and validation require those). Those can be null, though, too, if desired.

Hot Tip

If you are looking for a quick way to find this out yourself:

Create a table “apples” and an Apple model and add all types of fields you want to debug then call the model schema() like so:

debug($this->Apple->schema());

A second more persistent way would be to run the following command for such a test table (or any other real table for that matter):

cake schema generate

Anything missing?

I hope I didn’t forget anything. Otherwise please correct me!

Note: The “setup” bake theme is written for 2.x but can easily be backported to 1.3 manually.

Outline

We probably all know how xxxxxxx powerful the Bake tool is. It is all about speed for the first outline of a project. So the faster the first CRUD controllers are baked the sooner we can dig into the details. But speed itself is not the only crucial part. If we have a model/table with a lot of meta fields that should not get baked we would have to remove them manually from index/view/form every time we re-bake. That’s not really something you want to waste your time with.

Skip Fields

With some custom template like mine you can skip certain fields for baking. Some like 'password', 'slug', 'lft', 'rght' are automatically skipped by my template. But you can also define additional fields yourself:

class Deadline extends AppModel {
    public $scaffoldSkipFields = array('note');
}

An additional feature I want to implement is that you can specify the actions it should skip:

public $scaffoldSkipFields = array('note'=>array('prefix'=>'', 'actions'=>array('index')));

public $scaffoldSkipFields = array('note'=>array('prefix'=>'admin')); // skip for all admin views

Default Values

class User extends AppModel {
    public $scaffoldDefaultValues = array('role_id' => 'ROLE_USER', 'status' => 'User::STATUS_ACTIVE', 'level'=>1, 'text'=>'\'foo\'');
}

if ($this->request->is('post')) {
    ...
} else {
    $this->request->data['User']['role_id'] = ROLE_USER;
    $this->request->data['User']['status'] = User::STATUS_ACTIVE;
    $this->request->data['User']['level'] = 1;
    $this->request->data['User']['text'] = 'foo'; 
}

PS: Why not in the form itself? It is always better to put default values as a part of the logic into the controller and outside of the view layer.

Enum support

This article describes how to setup enums in CakePHP the easy way. Do this after you bake the model and BEFORE you bake controller and views. Then you will end up with ctps including all the Enum things automatically like a dropdown box for forms and translated values for index and view.

Smarter theme

We already covered a few basic field types before:

} elseif ($schema[$field]['type'] == 'date') {
    // formatted date
} elseif ($schema[$field]['type'] == 'boolean') {
    // yesNo image
} elseif ($schema[$field]['type'] == 'text') {
    // nl2br(h())
}

} elseif ($schema[$field]['type'] == 'float' && strpos($schema[$field]['length'], ',') !== false) {
    echo "\t\t<dd>\n\t\t\t<?php echo \$this->Numeric->money(\${$singularVar}['{$modelClass}']['{$field}']); ?>\n\t\t</dd>\n";
}

Usage

The files are in the Templates folder of my setup plugin.

Since my plugin theme might contain stuff you cannot and don’t wont to use you can cherrypick the above “tricks” for your own custom bake theme.

Now you know how you can further customize your themes to make baking even more fun as it already is

Periodic Table

A pretty geeky site shows the number of elements used on a website as a periodic table: periodic-table. Move over the elements with your mouse to see the count.

A CSS3 Generator

This Generator can easily generate valid and clean CSS3.

CakePHP Decorator Approach

I am not yet sure what to think about the cakephp-decorator-plugin. Will have to dig into it a little bit deeper. It seems that the decorator here uses markup at a very early stage. Maybe too early? It might be better to address this further down (on a helper level). I will sure look into it some time soon.

.. more coming

MCV?

Model - View - Controller.

What’s the big deal?

It had been bugging me for years that we had to do something like this in our controllers and models:

# hold on tight - bad part - start (already cake 2.0 style):
App::uses('TimeHelper', 'View/Helper');
App::uses('View', 'View');
$Time = new TimeHelper(new View(null));
$message = 'Your flier expired on ' . $Time->nice($flier['Flier']['expires']); # flash message or email title etc
# bad part - end

With Cake2.1 we can now do:

App::uses('CakeTime', 'Utility');
$message = 'Your flier expired on ' . CakeTime::nice($flier['Flier']['expires']);

Same thing with NumberHelper and CakeNumber:

App::uses('CakeNumber', 'Utility');
$filesizeString = CakeNumber::toReadableSize($filesize);

Last but not least the TextHelper methods have also been moved to the String class:

$shortext = String::truncate($longtext);

And for the View layer itself nothing changes. The helpers work as before, only they now use the lib classes internally.

Going one step further

You can even pass in your own engines (lib classes) for the view helpers. For example by passing it into the helper settings:

public $helpers = array(..., 'Time'=>array('engine'=>'Tools.TimeLib'));

I use this approach:

class TimeExtHelper extends TimeHelper {
    public function __construct($View = null, $settings = array()) {
        $settings = Set::merge(array('engine' => 'Tools.TimeLib'), $settings); // instead of core CakeTime lib
        parent::__construct($View, $settings);
    }
}

public $helpers = array(..., 'Time'=>array('className'=>'Tools.TimeExt'));

But if…

…if you still need to use helpers in the controller or model context? Well, then you are obviously still doing something wrong. There is absolutely no need for it anymore. And now no excuses anymore, either

You should move your code to the Lib folder as a package. Then use it in your controller as Lib class and in your View call the helper which then calls the Lib class. This way you keep it dry and simple. Just look how it is done in those classes above in the core.

Example: MathHelper.php

We might need its basic methods in the controller somewhere. The helper only adds markup or View related goodies. So we have a MathLib class in APP/Lib/Math (the Math package can also be any other name you want). And a MathHelper class in APP/View/Helper which uses the MathLib. Either the lazy way:

public function __call($method, $params) {
    return call_user_func_array(array($this->Math, $method), $params);
}

public function calculate($value) {
    return $this->MathLib->calculate($value);
}

And in the controller we do (let’s say we put the code in a “Tools” plugin):

App::uses('MathLib', 'Tools.Math'); # would then be in /APP/Plugin/Tools/Lib/Math/
$newValue = MathLib::calculate($value);

$this->loadHelper('Tools.Math'); # would be in /APP/Plugin/Tools/View/Helper/
$newValue = $this->Math->calculate($value);

PS: I like to suffix my lib classes with Lib to avoid naming conflicts with Models or other cakephp or php classes. This is not required, of course. But I would recommend it as long we cannot use namespaces (which will be Cake3.0 and is still quite a few miles away).

Happy coding!

Status quo

We would need to check the session manually against the roles we want to grant access to. This can get pretty hairy with more than one role allowed (if admins and moderators are allowed to see this box for example).

Preparations

We first need to make the class usable by putting this in our /Config/bootstrap.php:

// these IDs match the role_ids in the DB
define('ROLE_SUPERADMIN', '1');
define('ROLE_ADMIN', '2');
define('ROLE_MOD', '3');
define('ROLE_USER', '4');
 
// enable the Auth class
App::uses('Auth', 'Tools.Lib');

Then we need to decide whether we use single role (cake default) or multi role Authorization. I usually always use multi-roles. Therefore the default case for the Auth class is exactly this. The session then contains:

Auth.User.Role (with Role being an array of role ids)

Auth.User.role_id (with role_id being the single role we want to check against)

define('USER_ROLE_KEY', 'role_id');

“Former” usage

For comparison I will outline the manual and “outdated” way of authorization first:

# we want to make sure that piece is only visible to admins and moderators
if ($this->Session->read('Auth.User.role_id') == ROLE_ADMIN || $this->Session->read('Auth.User.role_id') == ROLE_MOD) {}
 
# or with multi-role
if (in_array(ROLE_ADMIN, (array)$this->Session->read('Auth.User.Role')) || in_array(ROLE_MOD, (array)$this->Session->read('Auth.User.Role'))) {}

Quite a lot to write…

Note: This also only works in controller/component and view/helper scope. You would have to use the static CakeSession::read() in order to make this work in the model/behavior one etc.

Usage

Now the fun part. The wrapper class can be found in the Tools Plugin.

# Same thing as above
if (Auth::hasRoles(array(ROLE_ADMIN, ROLE_MOD)) {}

The default case is that if one of the roles is matched it will return true right away. If you want to connect them with AND instead of OR, you need to make the second param false:

# This only passed if the user has both roles!
if (Auth::hasRoles(array(ROLE_ADMIN, ROLE_MOD), false) {}

If we only want to check against a single role we could also use the shorthand:

if (Auth::hasRole(ROLE_MOD) {}

Advanced usage

You can also pass in the roles you want to check against. This can be useful if you want to check somebody else’s roles (and not your session roles). This can come in handy in CLI (command line / shell) environment and also in the admin backend.

if (Auth::hasRole(ROLE_MOD, $rolesOfThisUser) {}

if (Auth::hasRoles(array(ROLE_MOD, ROLE_USER), true, $rolesOfThisUser) {}

And there is more

There are also some convenience methods available.

Instead of $uid = $this->Session->read('Auth.User.id') you can just write

$uid = Auth::id(); // anywhere in your application

The roles can be fetched like this:

$myRoles = Auth::roles(); // string in single-role and array in multi-role context

Last but not least the user data:

$user = Auth::user(); // complete user array
$username = Auth::user('username'); // string: current username
...

Final notes

Although this wrapper can be used about anywhere in your application with ease does not mean one should do that. Try to avoid using the auth (and therefore session) data in the model layer, for instance. Those should be kept state-less. But I also know that there are cases where it is pretty convenient to ignore this warning

Disclaimer

Just for clarification: This class does not provide you with the Authentication or Authorization. This has to be up and running already. It is only a wrapper to check user roles a more efficient and cleaner way.

So if you need to setup a fresh authentication, you can just use the cake Form authenticate for example. If you want multi-role authorization you would want to throw in some additional spices: You would need to write the Role array to your session upon successful login for the authorization module to work. See the above notes on how the session data array should look like.

For a new authorization take a look at my TinyAuth. It can handle single and multi role auth and those classes work well together (yeah – they have been designed to do that, of course^^).

I want to outline some ideas on how to chose the appropriate class type if you want to add some additional feature to your cake app. For a beginner it might be difficult to decide what to use in which case. Hope this article helps to clarify things. Feel free to comment on this below.

Overview

• bootstrap functions (most generic methods – no class context)
• Lib (most generic class)
• Helper (view level)
• Component (controller level)

And of course the base classes: Datasource, Model and Controller (and View).

Level of Independence

We need to ask ourselves if this feature needs to interact with other cake elements, like controller, some components, models, …

If it needs to save to the session, or if it needs some controller functionality, it will have to be a component. With initialize(Controller $controllerReference) and startup(Controller $controllerReference) this is very easy to accomplish.

With Cake13 libs have been introduced. Not every piece of “controller” code necessarily needs to be component anymore. So if you retrieve an RSS feed or get the weather from a weather channel web service you could just make a clean and independent lib class. No need to extend the cake object or even pass the controller reference. Less memory and dependency is a good thing. And its easier to test, anyway.

Helpers are used if the result is in relation to the view – in other words if it gets printed/echoed right away. If you want to retrieve some web service information and save it to the database use a component instead.

Database related?

Often times we need to adjust some model data, we either use a component first and then pass it to the model or we use beforeValidate() and beforeSave() in the model. Same goes for the other direction (from model to controller): afterFind() or a component call afterwards. This is fine for custom changes. As soon as it could be something useful for several models, it might make sense to build a behavior. The code gets cleaner and your models more powerful.

Examples would be: “Last Editor/Last Change”, “Geocoding”, “Auto-Capitalize first letter of name/title”, “Format/Localize Date/Time”, …

Reducing code redundancy

Now that we have a vague understanding where to use what type of tool, we should think about cutting down the redundancy. Lets say we use the vendor class “phpThump”. We would have to write two wrappers. one for the helper (display images in the view) and one for the component (uploading images and resizing), maybe even for some behavior (validating + uploading + resizing). This wrapper handles default values from Configure::read() and other cake related settings. In this scenario we should build one single library in /Lib, maybe called PhpthumbLib.php. Here we put our wrapper with our custom functions. Then we build a helper (view side) as well as a component or a behavior (controller side). They will import and use the library file. This is a cleaner approach because changes in the library class will be available in all files it is used in. Bonus: The main library file is easier to test. And therefore testing the other classes afterwards is easier, too.

Generally speaking, all web services should be some kind of library file (some would make a datasource out of it). It doesn’t matter then if we use it in components or helpers, because it will fit either way.

A helper in a controller, though, is not really a nice thing. With Cake2.1 there is no need to use helpers in the controller or model code anymore. All text/number/time helper methods have been moved to the Utility package and can now by used from anywhere within your application in a dry and clean way:

App::uses('CakeNumber', 'Utility');
$myValueInPercent = CakeNumber::toPercentage(45.12, 0); // or dynamically - but statically is easier in this case

Plugin or not?

If your feature is not site-specific but very generic it probably makes sense to build a plugin. This way all other apps can easily use the same plugin. Additionally, test cases, assets etc are all combined in one folder – clean and extendable.

Examples: A bookmark helper usually can be used in several apps, whereas a custom helper with two functions for this one app will not be very useful anywhere else.

Usage of those resources

For components, add it to the controller in order to use it in the corresponding actions:

var $components = array('MyC'); # file is in /APP/controllers/components named MyCComponent.php

$this->MyC->foo();

For helpers, add it to the controller in order to use it in the corresponding views:

var $helpers = array('MyH'); # file is in /APP/View/Helper named MyHHelper.php

$this->MyH->foo();

Libs can be used everywhere – include them at runtime:

App::uses('MyL', 'Lib'); # file is in /APP/Lib/ named MyL.php
$MyL = new MyL();
$result = $MyL->foo($input);

Sidenote: I like to keep those files appended with a suffix, as well (Lib to avoid collisions with other classes or core classes):

App::uses('MyLLib', 'Lib'); # file is in /APP/Lib/ named MyLLib.php
$MyL = new MyLLib();

Also note that you are encouraged in 2.x to group your lib classes in packages. So if you have some Utility Helper of your own, you might want to create a subfolder for it (you can use the core folder names or your own naming scheme):

App::uses('MyUtilityLib', 'Utility'); # file is in /APP/Lib/Utility/ named MyUtilityLib.php
$MyL = new MyLLib();

App::uses('UrlCacheManagerLib', 'Tools.Routing'); # file is in /APP/Plugin/Tools/Lib/Routing/ named UrlCacheManagerLib.php
$UrlCacheManager = new UrlCacheManagerLib();

Behaviors and other elements are used similar to the above.

For Plugins simply add the plugin name: “Text” becomes “Plugin.Text” etc

bootstrap functions: If those functions are so generic that you want to use them like h() or env() you can define them in your bootstrap. But be aware that this can lead to chaos if you do that for too many things.

Hacks for special use cases

Sometimes we need to break MVC in order to avoid redundance (and stay DRY). If a helper has to be available in a controller we need to manually include it then at runtime:

App::uses('MySpecialHelper', 'Helper');
App::uses('View', 'View');
$MySpecialHelper = new MySpecialHelper(new View(null));
$myText = $MySpecialHelper->foo($myText);

In this case we extend the CakeEmail Utility Lib class and add some fixes as well as some enhancements. The full list can be obtained from the documentation of the class itself which can be found in the Tools Plugin.

Usage

First things first: How will it be used? Not so much different from the core class. But we don’t need to set the defaults (as the wrapper utility takes care of that). The idea is to make it as DRY (don’t repeat yourself) as possible. So it is just:

App::uses('EmailLib', 'Tools.Lib');
$this->Email = new EmailLib();
$this->Email->to($email, $name);
$this->Email->replyTo(Configure::read('Config.admin_email')); //optional
$this->Email->subject($subject);
$text = '...';
$this->Email->viewVars(compact('text'));
return $this->Email->send();

It is also a good idea to store all site wide email addresses in your Configure, as well. In the above example the admin email + name for the optional replyTo part. Never write those addresses in your code – it will end up redundant at some point and lead to problems.

Requirements

You should set the following config values in Configure:

Configure::write('Config.admin_email', 'youremail');
Configure::write('Config.admin_emailname', 'yourname');

Main improvements

I will outline only the most important ones which made me use this wrapper class in all 10+ projects for a clean and easy email functionality.

Extended Logging

With report=>true you get quite verbose log output saved to email (to, from, subject), email_trace (complete email content) and email_error for SMTP and other errors.

No mails in debug mode

If you are in debug mode the emails get only saved to the above email_trace.log – they will not actually be sent. This is very helpful in development (no accidental emails to live customers etc).

Note: This requires the BaseEmailConfig of the Setup plugin (you can also copy and paste that piece of code, of course). The setup for your APP/Config/email.php would then be:

App::uses('BaseEmailConfig', 'Setup.Lib');
 
class EmailConfig extends BaseEmailConfig {
    ...
}

Embedded Attachments

This will automatically set the contentId and mimeType of the file. This is necessary for embedded attachments.

$this->Email->addEmbeddedAttachment('/some/file.ext', 'Some custom name');

Blob Attachments – as real attachment

This will automatically set the mimeType of the file (using the filename you provide).

$this->Email->addBlobAttachment($somePngFileBlobContent, 'my_filename.png');

Embedded Blob Attachments

This will also automatically set the mimeType of the file as above. But it will set the contentId, as well. This is necessary for embedded attachments.

$this->Email->addEmbeddedBlobAttachment($somePngFileBlobContent, 'my_filename.png');

No Exceptions thrown outside the wrapper

This is quite important because usually no one wraps his email sending functionality with try-catch-blocks. The wrapper catches those exceptions and logs them and will simply return false.

Other improvements

There is more, of course. Like the possibility to set the password and other security sensitive information via non-version-controlled config file (Configure::read/write). But those a minor things that will probably only be used by me. Or the possibility to override the X-Mailer header.

Example on how to set the configs dynamically via config:

// only the pwd
Configure::write('Email.Pwd.default', 'mypwd');
 
// complete email config
Configure::write('Mail.use_smtp', true);
Configure::write('Mail.smtp_username', 'username');
Configure::write('Mail.smtp_password', 'pwd');
...

Main fixes

The core class has a problem with valid message ids in shell environment as of cake2.1 and will probably be fixed in 2.2. Until then the wrapper also takes care of that.

You can just set the domain manually from the CLI to “simulate” the environment you are under:

$this->Email->domain('www.mydomain.com');

With my recent contribution to the 2.1 core pretty much all of my helpers, components, behaviors, models, … are now finally E_STRICT compliant. Which does not only make me happy, it also makes me think if I can drop my personal E_STRICT boycott now.

Most of those notices resulted out of incorrect method declarations. They have to be of the same type as the parent (some type, same number of params, …) which sometimes can get really annoying if you want to override a parent method. Depending on the specific case you can either use a separate method which then calls the original parent method or you can try to use composition (instead of inheritance). And if worst comes to worst: with 5.4 we could now use traits to overcome that obstacle.

Note: If you want to test your script with E_STRICT in PHP <= 5.3 you need to change your core.php error level:

Configure::write('Error', array(
    'handler' => 'ErrorHandler::handleError',
    'level' =>  E_ALL | E_STRICT, // meaning: E_ALL + E_STRICT (using binary operators)
    'trace' => true
));

How does a overriden method now look like?

It always a good idea to first take a look at the parent class your class inherits from. The method declaration can then easily be copy-and-pasted. This way nothing gets accidently swept under the rug.

A side note: You should also make sure that you call the parent method for callbacks. This is often forgotten and can lead to strange events. This parent method could do something important that would otherwise be missing.

public function initialize(Controller $controller) { 
    parent::initialize($controller); # important call
 // one stuff
}

Concrete examples

The controllers are pretty easy. Except for maybe beforeRedirect the other callbacks don’t have any params:

public function beforeRedirect($url, $status = null, $exit = true) {}

Helpers are also straight-forward:

public function afterRender($viewFile) {}
 
public function beforeLayout($layoutFile) {}

More interesting are the components and behaviors, for example. Part of my contribution was adding the overdue type hinting declarations (until now some classes had them, some don’t). All classes that use objects should now have them properly outlined in the method declaration:

// a component (for example my Common component)
public function initialize(Controller $controller) {}
 
public function beforeRedirect(Controller $controller, $url, $status = null, $exit = true) {}
 
// a behavior (for example my Bitmasked behavior)
public function setup(Model $Model, $config = array()) {}
 
public function afterFind(Model $Model, $results, $primary) {}
 
public function afterSave(Model $model, $created) {}
 
public function beforeDelete(Model $model, $cascade = true) {}

Hopefully, with those tips, you will be able to get your app E_STRICT compliant. Happy coding!

Final tips

Coders are lazy! We don’t want to do things manually if we can help it. It is possible to get some of the necessary changes done via upgrade shell. At least I did it this way. Check it out (cake Upgrade.Correct reference) or write your own shell commands. The huge advantage: Once written you can update as many apps as you want with a single click.

In a previous post I already pointed out the possibilities for traits – although I am not quite sure yet how it could benefit current cake projects.

This article describes some more news and features regarding this new release.

I certainly won’t use any of the “syntactic sugar” like short array syntax anytime soon. It would just break with the current way of writing arrays – and then one would end up with two different syntaxes in the same app or even class. But some of new features (besides the traits) sure look promising!

What will you be using? Or is there – especially regarding cake – no real use for any of those new features?

Setting additional attributes for some select options

You might want set some option elements to a specific class. The FormHelper::select() is powerful enough to support this:

// normal options
$options = array(1=>'One', 2=>'Two', 3=>'Three');
 
// advanced (second elements has a class "extra")
$options = array(1=>'One', 2=>array('name'=>'Two', 'value'=>2, 'class'=>'extra'), 3=>'Three');
 
echo $this->Form->input('test', array('type'=>'select', 'options'=>$options));

<div class="input select">
    <label for="ModelTest">Test</label>
    <select name="data[Model][test]" id="ModelTest">
        <option value="1">One</option>
        <option value="2" class="extra">Two</option>
        <option value="3">Three</option>
    </select>
</div>

You might want to check this site here if the styles you want to apply work in all browsers. Usually only some styles like background-color are apply-able cross-browser.

Autofocus

Not so much CakePHP as maybe HTML5 – but pretty useful for login forms:

echo $this->Form->input('login', array('autofocus'=>'autofocus'));

More HTML5 out-of-the-box

In general HTML5 is great, but still not fully supported by all browsers – or users just don’t update to a new version. So we shouldn’t completely rely on those features. But where – as the above autofocus – the absence in unsupportive browsers doesn’t bother anyone we can easily apply those features for users with modern browsers.

Additionally, we can use fallback-js to “simulate” the behavior if not natively supported. I put together a well-working HTML5-fallback script for jquery. It checks if the browser supports a certain feature and if not it creates a JS workaround.

I bet there are lots of other similar implementations. The important part for those placeholders is that on submit the content needs to be cleared again. The placeholders must not be posted (otherwise your validation rules might not work as expected anymore). I used the $('form').live('submit', function() {} event to clear the forms in time.

echo $this->Form->input('url', array('placeholder'=>'http://'));

Structure your controllers

You don’t have to put all 40ish actions that are related to the User model in a single UsersController. Divide them to keep things clean and clear. So for me this worked pretty well:

• AccountController (login, logout, register, change_pw, edit, …): $uses = array('User')
• MembersController (index, search, profile, mail, friend, …, admin backend actions): $uses = array('User')
• OverviewController (index, admin index, … – specially routed): $uses = array('User')

As you can see they all use the user model but they separate the actions by category. This way the file stays kinda short and is better understandable in the long run. Imagine all those actions in a single controller. No way

Controllers without models

Until today you coudn’t just set $uses to false in Cake2. What used to work in 1.3 will fail hard in 2.x. It was a pretty annoying problem I reported right away (but it needed a second one to actually get things into motion). If you just used isset($this->Model) it would try to load a non-existent model and die. The current head now contains the new fixed version which works now the way one would expect it to work:

• true Use the default inflected model name.
• array() Use only models defined in the parent class.
• false Use no models at all, do not merge with parent class either.
• array('Post', 'Comment') Use only the Post and Comment models. Models will also be merged with the parent class.

The default value is true.

So basically, if we don’t want to use any models (or at least no default model):

class TestController extends AppController {
    public $uses = false;
}