So, how do I use it?

Actually, we will store extra data on another table so, first of all, you need to create this auxiliary table:

CREATE TABLE IF NOT EXISTS `options` (
  `id` int(11) NOT NULL auto_increment,
  `model` varchar(32) NOT NULL,
  `related_id` int(11) NOT NULL,
  `opt_key` varchar(32) NOT NULL,
  `opt_value` text NOT NULL,
  PRIMARY KEY (`id`),
  KEY `opt_key` (`opt_key`)
);

If you can’t have a new table named ‘options’, don’t worry. Just name it something else. Now you need to create the model file for this table. Something like this should be enough:

class Option extends AppModel { }

If you are using a different table name, don’t forget to change the class name to whatever other name you have for it. Now you can download the behavior file here. Place it under your behaviors folder.

Now what?

Let’s pretend that you have a model named Blog which has three columns on it’s table: id, title and content. Generally, if I want to extend this table, I’ll have to deal with it’s schema, but using the Optionable Behavior, things get really easy. Imagine that I want to add my mood and the current weather to some posts on the blog. I just have to do something like this:

public $actsAs = array(
	'Optionable' => array(
		'model' => 'Option',
		'fields' => array('mood', 'weather'),
		'emptyFields' => true
	)
);

Now I can just put those extra keys on a form, save some data and that is it. The data will be retrieved from the database just like if they were from the Blog’s schema itself.

See that we have three configuration keys to the behavior:

• model: defaults to ‘Option’. Just define this if you are using a different table name.
• fields: no default. Here you can define every optional field that you want to use in your model.
• emptyFields: defaults to true. If true, even if that option is not registered on the auxiliary table, the key will be present on the data array.

This behavior tries it’s best to make every optional field feels like a native one. This means that you can save, validate and retrieve optional data just like you would with common fields. We are working to make it possible to filter data by optional fields as well.

A great benefit of using this behavior is that you can store different data types on the DB seamlessly. Every data is serialized before getting saved to the table. That means that you can store arrays, objects and other data types not natively supported by RDBMSs without having any trouble converting them as they come and go.

Well, I guess this is it. If you have any idea on how to make this work any better, please, share with us! Here is the code:

Here is a simple function that helps me to sort elements in a MySQL database by it’s ID’s:

If that is usefull to you, let me know!

This is particularly useful to create SEO links out of, for example, a table of articles. Instead of seeing those ugly /articles/view/4 URLs, use the Sluggable Behavior and easily accept URLs such as /articles/view/my-seo-friendly-article. It handles the slug creation, slug collision, and allows you to specify different settings such as the separator to use, maximum width of a slug, among other useful parameters.

My Sluggable Behavior is a simpler version of Mariano Iglesias’ Sluggable Behavior with a few add-ons. It’s basically the same thing but instead of implementing all the slug logic on the behavior, it just uses Cake’s Inflector::slug() method. With CakePHP 1.3, this method is really powerful and flexible.

To use it, just place the behavior file on the proper place and call it on the model you want to “slugify”:

var $actsAs = array('Sluggable');

By default, this will automatically create slugs from a field named “title” and place it under a field named “slug”. If you want, you can customize everything. Checkout the configuration keys:

var $actsAs = array(
	'Sluggable' => array(
		'fields' => 'title',
		'scope' => false,
		'conditions' => false,
		'slugfield' => 'slug',
		'separator' => '-',
		'overwrite' => false,
		'length' => 256,
		'lower' => true
	)
);

Those are all the default values. Let’s check what they can do, one by one:

• fields: as you can see, this is where you define which field will provide the content to the slug. You can inform more than one with an array.
• scope: after generating a slug, the system will check for similar slugs on the database in order to generate a unique slug. By default, it will scan all your registries, but you can define scopes. Example: you want the system to use an already registered slug on a different category. You can define an array like this: ‘scope’ => array(‘category_id’). The system will only check for records where the “category_id” is the same from the data being saved.
• conditions: these are extra conditions you can inform. The system will scan for similar slugs previously registered on the database using those conditions as well. They work just like a normal find conditions array.
• slugfield: the name of the field that will store the slug on the database.
• separator: the character that will be used to replace white spaces on the slug.
• overwrite: if true, this will replace the slug from a record on update, otherwise it will be kept untouched on a update.
• length: this defines the length of the slug text.
• lower: if false, the behavior won’t make the slug all lower case.

Once again, this behavior is totally inspired by Mariano Iglesias’ Sluggable Behaviour. If you want to help, please comment! Here is the source code:

Na verdade, na época a coisa já havia mudado, mas eu não sabia. Foi quando eu encontrei este outro artigo aqui. O artigo ensina como fazer joins em casos específicos utilizando o Model::find().

Então imagine que temos duas tabelas, uma de Posts e outra de Tags e exista uma relação HABTM entre elas. Eu quero encontrar todos os posts com a Tag “design”, como fazer?

Uma vez dentro do controller dos posts eu posso escrever o seguinte código:

Obs.: Este código não foi testado e seu objetivo é apenas o de ilustrar as possibilidades aqui apresentadas.

$posts = $this->Post->find('all', array(
	'joins' => array(
		array(
			'table'      => 'posts_tags',
			'alias'      => 'PostsTag',
			'type'       => 'INNER',
			'conditions' => array('PostsTag.post_id = Post.id')
		),
		array(
			'table'      => 'tags',
			'alias'      => 'Tag',
			'type'       => 'INNER',
			'conditions' => array(
				'Tag.id = PostsTag.tag_id',
				'Tag.tag LIKE' => '%design%'
			)
		)
	)
));

Trazendo um caso da vida real, na Quitanda eu queria mostrar os últimos posts de uma determinada categoria dentro do painel dos usuários com lojas. O nosso blog é feito com WordPress. Eu teria que criar um arquivo model para a tabela de posts do WP para poder fazer isso, mas fiquei com preguiça já que este seria o único lugar onde isto aconteceria, então ao invés de criar um arquivo de modelo, eu criei ele dentro do próprio controller utilizando a classe ClassRegistry e o método init.

Como minha tabela do WordPress era diferente da utilizada pela aplicação, primeiro eu defini um novo vetor de configurações no meu arquivo config/database.php. Veja:

var $wp = array(
	'driver' => 'mysql',
	'persistent' => false,
	'host' => 'localhost',
	'login' => 'user',
	'password' => 'password',
	'database' => 'qolwp',
	'encoding' => 'utf8'
);

Depois, já no meu controller, escrevi a seguinte linha:

$this->WpPost = ClassRegistry::init(array(
	'ds' => 'wp',
	'table' => 'wp_posts',
	'class' => 'model',
	'alias' => 'WpPost'
));

Os parâmetros praticamente se auto explicam mas, a chave ‘ds’ guarda a variável de configuração do banco que vai ser utilizada, no caso ‘wp’, como definido anteriormente. Depois dizemos qual é a tabela a ser utilizada, o tipo de classe a ser registrada e o ‘alias’ para ser utilizado nas consultas.

Depois eu fiz a consulta. Ela ficou meio extensa e é claro que escrevendo isto direto no SQL seria muito mais simples, mas fica aqui a titulo de exemplo. Eu fiz isso mais para experimentar as possibilidades e ver o que acontecia. Olha só:

$posts = $this->WpPost->find('all', array(
        'joins' => array(
                array(
                        'table' => 'wp_term_relationships',
                        'alias' => 'WpTermRelationship',
                        'type' => 'INNER',
                        'conditions' => array('WpPost.ID = WpTermRelationship.object_id')
                ),
                array(
                        'table' => 'wp_term_taxonomy',
                        'alias' => 'WpTermTaxonomy',
                        'type' => 'INNER',
                        'conditions' => array('WpTermRelationship.term_taxonomy_id = WpTermTaxonomy.term_taxonomy_id')
                ),
                array(
                        'table' => 'wp_terms',
                        'alias' => 'WpTerm',
                        'type' => 'INNER',
                        'conditions' => array('WpTermTaxonomy.term_id = WpTerm.term_id')
                )
        ),
        'conditions' => array(
                'WpPost.post_type' => 'post',
                'WpPost.post_status' => 'publish',
                'WpTermTaxonomy.taxonomy' => 'category',
                'WpTerm.slug' => 'painel'
        ),
        'fields' => array(
                'WpPost.post_title',
                'WpPost.post_content',
                'WpPost.guid',
                'WpPost.post_date'
        ),
        'group' => 'WpPost.ID',
        'order' => 'WpPost.post_date DESC',
        'limit' => 5
));

O SQL que esta função vai criar fica assim:

SELECT `WpPost`.`post_title`, `WpPost`.`post_content`, `WpPost`.`guid`, `WpPost`.`post_date` FROM `wp_posts` AS `WpPost` INNER JOIN wp_term_relationships AS `WpTermRelationship` ON (`WpPost`.`ID` = `WpTermRelationship`.`object_id`) INNER JOIN wp_term_taxonomy AS `WpTermTaxonomy` ON (`WpTermRelationship`.`term_taxonomy_id` = `WpTermTaxonomy`.`term_taxonomy_id`) INNER JOIN wp_terms AS `WpTerm` ON (`WpTermTaxonomy`.`term_id` = `WpTerm`.`term_id`) WHERE `WpPost`.`post_type` = 'post' AND `WpPost`.`post_status` = 'publish' AND `WpTermTaxonomy`.`taxonomy` = 'category' AND `WpTerm`.`slug` = 'painel' GROUP BY `WpPost`.`ID` ORDER BY `WpPost`.`post_date` DESC LIMIT 5

Com isto você já pode ver que existem muitas possibilidades. Por exemplo, você pode fazer consultas com LEFT JOIN ao invés de INNER JOIN simplesmente trocando a chave ‘type’. Veja também que nas condições gerais da minha consulta eu pude colocar filtros diretamente relacionados às tabelas que eu dei join. No artigo original existe uma chave ‘foreignKey’ com valor false, mas analisando a API, não achei nenhuma referência a este valor em nenhum dos adaptadores de bancos de dados, então me parece ser algo totalmente dispensavel e a função funciona sem que ela seja declarada.