Read the full article

Motivation

This paper is intended to try to improve the next version of Cake. I think one of the most important features of a framework is its capacity to be expanded. Plugins achieve that gracefully. But there is a problem; plugins, as read on tempdocs, are meant to be packages. I think they can be much more. This is mainly a software design problem.

Where they fail

Point #1

Cake creates conventions for everything turning controllers, models and views universal. Same happens to plugins, but because of namespace concerns it is recommended to developers to include plugins name in controllers, models and views names. So a blog plugin would have BlogPost and BlogComment as models, BlogPosts and BlogComments as controllers. That’s fine to me (and recommended) but the Router should be smart so it won’t be necessary URI’s like /blog/blogPosts.

Point #2

Second is its usefulness. I think plugins can be more than just isolated modules. Imagine a plugin that is mutable, just by receiving some variables on runtime. I think every experienced developer has come to a day where he finds himself coding same thing twice. With MVC architecture that is a problem which is 90% of the time solved, but here are exceptions.

This kind of problem appears on relative big websites. Imagine you have Users profile page, which can receive Comments. You also have the Groups page which can also receive Comments. Code can be reused by creating an element and invoking it on the view, passing the right data. That’s a simple example.

But, what if Users and Groups could have Images. The Images logic would be obviously be present in the Model, but what about all the actions? Could be achieved by /images/view/type:group/23. Still ok to me. But images now have Categories, Tags and Comments. That becomes kind of hard to maintain. Developer is responsible to persist the type and id, for the operations to succeed. A good solution to this problem would be packing all has a plugin, to get all things organized, but the persistent problem would still exist.

A Diagram

Solution

On the diagram there is an example of a common plugin: blog. Only controllers and their actions are represented, but it illustrates what I’m trying to say. Both Users and Clans have Blogs. Blog is a plugin. The only difference is that plugin is acting inside other controllers, by receiving simple data on runtime. That data will make the plugin mutable to various sources.

This is also the solution for the problem #2, on the previous chapter.

Some code, just for example

// plugins/blog/models/blog_post.php

BlogPost extends BlogModel
{
   $belongsTo = array('User'); // User is a global scope Model
   $hasMany = array('BlogCategory', 'BlogTag');
}

// plugins/blog/controllers/blog_posts_controller.php

BlogPostsController extends BlogController
{
   protected $sourceType;
   protected $sourceID;
}

// controllers/user.php

UsersController extends AppController
{
   public $extends = array(
       'profile' => array('blog', array('sourceType' => 'user', 'sourceID' => '#id')),
       'gallery' => array('gallery', array('sourceID' => '#id')));

}

// In this example, profile and gallery actions, extend to two different plugins.

My only concern with the design of this plugins is just one. The overhead of having to load the Users controller and then redirect to Blogs plugin is a waste. This can be avoided with smart extension, which would read (or cache) the extensions of a controller, before loading it.

Conclusion

There are still some code details which need to be improved, but still, the theory is here. I think Cake would win a lot by adding this simple feature. It would turn plugins mutable which would make extensibility easy.

Hoje vou apresentar uma função que a maior parte da comunidade PHP não conhece. Está englobada dentro das “funções mágicas”, foi íncluida no PHP5, mas é necessário defini-la.

Em projectos com uma escala média, em que contamos com mais do que alguns ficheiros é praticamente certo que vamos utilizar classes, e inclui-las com ficheiros externos.

Este é um exemplo típico duma aplicação simples/complexa. Incluímos o nosso ficheiro em todos as páginas em que vamos necessitar duma ligação à base-de-dados e em cada uma delas vamos iniciar o nosso objecto.

Agora podemos continuar a seguir a linha de pensamento, e para um projecto funcionar vai precisar também duma classe para gerir os utilizadores, outra, quem sabe, para gerir os templates – e para os mais exigentes, também podemos incluir uma para cache.

Vamos utilizar muito provavelmente uma página, normalmente denominada por kernel ou global, que vai incluir tudo isto por nós em todas as páginas, ou na única página, do nosso projecto.

Mas tudo fica mais simples se fizermos uso desta função. Imaginemos o seguinte pedaço de código, que representa literalmente como ficaria o nosso index:

Acho que já se tornou evidente as capacidades desta função. Quando criamos um novo objecto, se o interpretador não encontrar a class definida chama a função __autoload e passa como argumento o nome da class. Tudo o resto fica a cargo da nossa imaginação.

Esta função já é usado em frameworks do topo como codeignitor, cakephp e a recente, e aclamada, Zend Framework. Além disso está parcialmente provado que fica aproximadamente ~3.7x mais eficiente usar __autoload em vez de usar directamente o require_once.

Fica aqui um último exemplo de como eu uso esta função em algumas aplicações, tornando o meu código mais legível e incorporando um log de erros. Quando chamo uma class, cada _ (underscore) representa um nível mais baixo em pastas, permitindo assim organizar facilmente módulos e classes.

This area is intended for everyone new to PHP. It opens with a series of informal, entertaining tutorials written by Vikram Vaswani, founder and CEO of Melonfire. These tutorials build on a previously-published 5-part series which has now been updated and extended to embrace PHP 5, making parts of it suitable for those of you who already have worked with PHP 4 in the past.

If you came here to learn about elementary PHP 4 or basic PHP 5, this is for you. Enjoy!

PHP 101: PHP For the Absolute Beginner

Alguma vez pensou se seria possível executar ficheiros de php na linha de comandos, como se fossem programas de C ou de Pascal?

Além de parecer divertido, provavelmente já precisou mesmo de usar e não sabia como. Imagine um ficheiro em PHP que executaria quando iniciasse o servidor (ou o seu servidor instalado em casa) e que trataria de apagar mensagens de fórum antigas ou actualizasse as estatísticas de um gestor de ficheiros.

Podíamos criar um Crontab se estivéssemos a usar Cpanel ou Unix, mas por vezes precisamos de ir mais além. Em PHP existe mais uma opção chamada actualmente de CLI (Command Line Interface) a qual vamos explorar neste artigo.

O CLI

Desde a versão 4.3.0 do PHP que o CLI se tornou um um SAPI (Server API) oficial e conta agora com um .exe próprio para executar aplicações destinadas á linha de comandos.

É bom ter a noção de que o PHP não é a única escolha para criar aplicações que executem em linha-de-comandos, mas traz obviamente vantagens. Se estivermos a programar um portal poderíamos usar outra linguagem como PERL ou Python; o problema aparece quando não conhecemos bem a linguagem ou, mesmo que lidemos bem com ela, seria necessário um esforço extra para executar no mesmo servidor duas linguagens diferentes e lidarmos com a possibilidade de ter de corrigir problemas de duas linguagens diferentes. Simplesmente na grande maioria dos casos é preferível a simplicidade à performance que as outras linguagens dão.

Que tipo de problemas podem ser resolvidos utilizando PHP na consola? Podemos resolver problemas administrativos em que não necessitamos de criar grandes ambientes visuais, mas precisamos de mandar executar backups, limpeza de listas de comentários. Também podemos pensar em fazer um programa de instalação de linha de comandos; por vezes não temos pastas com acessos de escrita e então temos aqui uma boa solução.

Versão da PHP

Podemos correr qualquer versão do PHP na consola, mas é aconselhável que se use a partir da versão 4.3.0, pois implementa o novo sistema CLI. { Ver documentação PHP }

Antes de executarmos o comando é importante relembrar que não necessitam de ter a palavra php definida como um atalho no Windows; podem executar directamente através da pasta. Para os utilizadores de Linux este problema não se coloca.

C:\wamp\php>php -v
PHP 5.2.3 (cli) (built: May 31 2007 09:37:22)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

ou

$ php -v
PHP 4.3.6 (cli) (built: Apr 19 2004 10:02:14)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

É aconselhável que obtenham a confirmação que têm o cli, mas se obtiverem um cgi não se preocupem pois pode ser contornado. Mais à frente veremos como.

O Básico

Para começar, é importante perceber que qualquer script em php vai funcionar correctamente na linha de comandos. Mas também é imediato a percepcção que o output não vai ser tão bonito como visto num browser.. ; )

É portanto preciso adaptarmo-nos quando estamos a programar um script a ser executado para a linha de comandos. Aqui fica um exemplo muito simples:

Para executar este programa, vamos novamente à consola:

C:\wamp\php>php hello.php
Ola Consola! :D

ou

C:\wamp\php>php C:\caminho_para_ficheiro\hello.php
Ola Consola! :D

Mais avançado

É importante perceber mais conceitos. Quando se escreve programas para consola, devemos incluir um exit(0); no final do programa respeitar as regra de “boas maneiras”. Além disso os parágrafos funcionam de forma bem mais simples sendo apenas necessário um \n no final da linha, ao contrário de um <br> ou <p>.

<?php
for ( $i = 0; $i

Output

C:\wamp\php>php loop.php
0
1
2
3
4
5
6
7
8
9

Quando estivermos a programar para consola, vamos utilizar duas novas funções: fgets e fwrite. Qualquer pessoa familiarizada com outras linguagens já conhece estas funções. Elas recebem como argumento um stream de dados.

Existem três stream’s que vêem por defeito no PHP, associadas a estes endereços:

• php://stdin (leitura) – STDIN
• php://stdout (escrita) – STDOUT
• php://stderr (escrita) – STDERR

Conseguiríamos um programa exactamente igual com esta alternativa:

<?php
for ( $i = 0; $i

Ler dados

Obviamente em algum ponto vai ser necessário o utilizador faz algumas escolhas dentro da execução do programa.

Podemos pensar que estamos a lidar com um ficheiro, que torna tudo mais fácil de imaginar. A única diferença é que usamos os stream’s de input e output do PHP. A constante que sobra, STDERR, serve para guardar erros de execução numa stream independente; estudaremos mais em pormenor noutro artigo.

function foo() {
    return "Hello Blog!n";
}

for ($i = 0; $i < 10 $i++) {
    echo foo();
}