Você está na página 1de 75

CENTRO UNIVERSITÁRIO DE MARINGÁ

CURSO DE PÓS-GRADUAÇÃO EM DESENVOLVIMENTO ORIENTADO A

OBJETOS - JAVA

LEANDRO APARECIDO JACOMETE

FRAMEWORKS PARA DESENVOLVIMENTO WEB: COMPARATIVO ENTRE OS


FRAMEWORKS PARA DESENVOLVIMENTO WEB COM MVC JAVASERVER
FACES E CAKEPHP

MARINGÁ
2012
LEANDRO APARECIDO JACOMETE

FRAMEWORKS PARA DESENVOLVIMENTO WEB: COMPARATIVO ENTRE OS


FRAMEWORKS PARA DESENVOLVIMENTO WEB COM MVC JAVASERVER
FACES E CAKEPHP

Monografia apresentada ao Centro


Universitário de Maringá como requisito
para obtenção do título de especialista em
Desenvolvimento Orientado a Objetos -
JAVA, sob orientação do Prof. Msc. Edson
Yanaga.

MARINGÁ
2012
LEANDRO APARECIDO JACOMETE

FRAMEWORKS PARA DESENVOLVIMENTO WEB: COMPARATIVO ENTRE OS


FRAMEWORKS PARA DESENVOLVIMENTO WEB COM MVC JAVASERVER
FACES E CAKEPHP

Monografia apresentada ao Centro Universitário de Maringá, como requisito parcial à


obtenção do título de Especialista em Desenvolvimento Orientado a Objetos – JAVA.
Orientação: Prof. Msc. Edson Yanaga.

BANCA EXAMINADORA

Orientador:
_______________________________
Msc, Edson Yanaga
CESUMAR

Membro:
_______________________________
Msc, César Fernando Moro
CESUMAR
Dedico este trabalho a Deus, minha esposa e todos que colaboraram

com a criação do mesmo...


AGRADECIMENTOS

Ao meu orientador que me ajudou em todos os momentos e me incentivou


para término deste.
A minha esposa que sempre me deu força e incentivo para a conclusão
deste curso.
RESUMO

FALTA FAZER
ABSTRACT
FALTA FAZER
LISTA DE FIGURAS

Figura 1 – Padrão MVC............................................................................................15


Figura 2 – Estrutura Funcional do CakePHP............................................................18
Figura 3 – Tecnologia JSF para UIs.........................................................................37
Figura 4 – Ciclo de Vida do JSF...............................................................................56
LISTA DE TABELAS

Tabela 1 – Componentes Principais CakePHP ........................................................27


Tabela 2 – FormHelper: Tipos Colunas / Campos Formulário .................................34
Tabela 3 – Termos Mais Importantes do JSF...........................................................38
Tabela 4 – Tipos de Eventos do JSF .......................................................................49
Tabela 5 – API javax.faces.event.ValueChangeEvent .............................................52
Tabela 6 – API javax.faces.event.FacesEvent .........................................................52
Tabela 7 – Tags Fundamentais do JSF....................................................................58
Tabela 8 – Tags HTML do JSF ................................................................................59
Tabela 9 – Principais Frameworks RIA para JSF.....................................................65
Tabela 10 – Bibliotecas para Interagir PHP com AMF .............................................67
SUMÁRIO

INTRODUÇÃO .........................................................................................................12
1 – FRAMEWORK....................................................................................................13
2 – CGI (COMMON GATEWAY INTERFACE) .........................................................14
3 – PADRÃO MVC (MODEL-VIEW-CONTROLLER) ...............................................15
4 – CAKEPHP ..........................................................................................................18
4.1 – Estrutura Funcional do CakePHP....................................................................18
4.1.1 – Extensões de controlador.............................................................................19
4.1.2 – Extensões de visão ......................................................................................19
4.1.3 – Extensões de modelo ...................................................................................20
4.1.4 – Extensões de aplicação................................................................................21
4.2 – Estrutura de Arquivos e Diretórios do CakePHP .............................................21
4.2.1 – Estrutura do diretório app .............................................................................22
4.3 – Convenções no CakePHP...............................................................................22
4.4 – Validação de Dados ........................................................................................23
4.5 – Testes no CakePHP ........................................................................................26
4.6 – Componentes Principais..................................................................................26
4.7 – Behaviors Principais ........................................................................................27
4.7.1 – ACL behaviors..............................................................................................27
4.7.1.1 – Utilização básica........................................................................................28
4.7.2 – Containable ..................................................................................................29
4.7.3 – Tree (Árvore) ................................................................................................30
4.8 – Helpers Principais............................................................................................31
4.8.1 – AjaxHelper....................................................................................................31
4.8.2 – FormHelper ..................................................................................................32
4.8.3 – CacheHelper ................................................................................................35
5 – JSF (JAVASERVER FACES) .............................................................................36
5.1 – MVC no JSF (JavaServer Faces) ....................................................................37
5.1.1 – Controller......................................................................................................37
5.1.2 – Model............................................................................................................37
5.1.3 – View..............................................................................................................37
5.2 – Serviços Importantes do Framework JSF (JavaServer Faces) .......................38
5.2.1 – Componentes UI...........................................................................................40
5.2.2 – Renderizador................................................................................................41
5.2.3 – Backing beans..............................................................................................42
5.2.4 – Escopo dos beans ........................................................................................43
5.2.5 – Validadores ..................................................................................................43
5.2.6 – Conversor.....................................................................................................46
5.2.7 – Eventos e ouvintes .......................................................................................49
5.2.7.1 – Eventos do ciclo de vida............................................................................50
5.2.7.2 – Eventos de alteração de valor ...................................................................50
5.2.7.3 – Eventos de ação........................................................................................52
5.2.7.4 – Eventos de fase.........................................................................................53
5.2.8 – Mensagens...................................................................................................54
5.2.9 – Navegação ...................................................................................................55
5.3 – Ciclo de Vida do JSF (JavaServer Faces).......................................................56
5.4 – Tags Fundamentais do JSF (JavaServer Faces) ............................................57
6 – COMPARAÇÕES ENTRE CAKEPHP E JSF (JAVASERVER FACES) .............61
6.1 – Documentação ................................................................................................61
6.1.1 – JSF (JavaServer Faces)...............................................................................61
6.1.2 – CakePHP......................................................................................................61
6.2 – Curva de Aprendizagem..................................................................................62
6.2.1 – JSF (JavaServer Faces)...............................................................................62
6.2.2 – CakePHP......................................................................................................63
6.3 – Integração com Outros Frameworks ...............................................................64
6.3.1 – JSF (JavaServer Faces)...............................................................................64
6.3.1.1 – Principais frameworks RIA para JSF (JavaServer Faces).........................65
6.3.2 – CakePHP......................................................................................................66
6.4 – Comunidades ..................................................................................................68
6.4.1 – JSF (JavaServer Faces)...............................................................................68
6.4.2 – CakePHP......................................................................................................69
CONCLUSÃO...........................................................................................................71
REFERÊNCIAS ........................................................................................................73
12

INTRODUÇÃO

Com o crescimento da tecnologia, o software torna-se cada vez mais


importante para o desenvolvimento das empresas. Com o advento da Internet e sua
rápida expansão surgiram os softwares voltados para web, que proporcionam o fácil
acesso ao mesmo sistema em qualquer lugar em que ela esteja, não apenas para os
usuários finais, mas também por grandes corporações, onde o tempo é dinheiro e
qualquer forma de integrar um processo de maneira rápida e eficiente é que faz dela
uma empresa diferenciada.

No início as aplicações web forneciam uma interação básica com o usuário,


permitindo que certos serviços simples pudessem ser executados através de uma
rede. Com isso, foram surgindo diversas arquiteturas e linguagens de programação,
muitas dessas deixaram de ser usadas no passar do tempo e outras se
consolidaram e se tornaram muito utilizadas no mercado. Destas tecnologias duas
foram destaques no desenvolvimento de software para a web o Java e o PHP.

O Java, que mesmo tendo surgido com um propósito diferente do uso em


aplicações web, evoluiu de modo a atender esta forte necessidade, iniciando com os
Servlets em seguida o JavaServer Pages os conceitos JavaBeans e Java Standard
Tags Library até chegar nos frameworks com modelo MVC como o JavaServer
Faces.

O PHP foi e é uma das linguagens de programação voltadas para a internet


que mais cresceu nos últimos anos em todo o mundo. A quantidade, diversidade e
qualidade de seus recursos, assim como a facilidade de utilização, foram os
principais fatores que alavancaram o seu uso em grande escala. Com seu
crescimento apareceram vários frameworks que utilizam o modelo MVC e um dos
frameworks mais utilizados é o CakePHP.

No decorrer desse trabalho será analisado os frameworks MVC JavaServer


Faces (Java) e CakePHP (PHP) abordando sua evolução, documentação e recursos
disponíveis para tornar o desenvolvimento ágil e de fácil manutenção.
13

1 – FRAMEWORK

Um framework ou arcabouço, em desenvolvimento de software é uma


abstração que une códigos comuns entre vários projetos de software provendo uma
funcionalidade genérica. Um framework pode atingir uma funcionalidade específica,
por configuração, durante a programação de uma aplicação. Ao contrário das
bibliotecas, é o framework quem dita o fluxo de controle da aplicação, chamado de
Inversão de controle.

Framework conceitual é um conjunto de conceitos usado para resolver um


problema de um domínio específico. Não se trata de um software executável, mas
sim de um modelo de dados para um domínio.

Framework de software compreende de um conjunto de classes


implementadas em uma linguagem de programação específica, usadas para auxiliar
o desenvolvimento de software.

O framework atua onde há funcionalidades em comum a várias aplicações,


porém para isso as aplicações devem ter algo razoavelmente grande em comum
para que o mesmo possa ser utilizado em várias aplicações.
14

2 – CGI (COMMON GATEWAY INTERFACE)

CGI é um acrônimo para a expressão inglesa “Common Gateway Interface”.


Consiste numa importante tecnologia que permite gerar páginas dinâmicas,
permitindo a um navegador passar parâmetros para um programa alojado num
servidor web. Assim, designam-se por scripts CGI os pequenos programas que
interpretam esses parâmetros e geram a página depois de os processar.

O CGI foi concebido como o culminar de discussões por especialistas


durante os primórdios da Internet, nomeadamente entre Rob McCool, John Franks,
Ari Luotonen, George Phillips e Tony Sanders.

Os CGI, porém apresentam problemas de portabilidade e escalabilidade,


além de mesclarem as regras de negócio com a visualização. Vale salientar que um
servidor que usa este tipo de tecnologia pode ter seu desempenho comprometido,
uma vez que cada solicitação recebida de uma CGI requer a criação de um novo
processo.

Embora a linguagem tipicamente associada aos CGI seja o PERL, o CGI foi
concebido por forma a ser independente da linguagem utilizada. Atualmente
tecnologias como ASP.NET ou PHP continuam a utilizar a especificação.
15

3 – PADRÃO MVC (MODEL-VIEW-CONTROLLER)

Originalmente foi criado como padrão de projeto arquitetural desenvolvido


para o ambiente Smalltalk, mas ele pode ser utilizado para qualquer aplicação
interativa.

Com o aumento da complexidade das aplicações desenvolvidas torna-se


fundamental a separação entre os dados (Model) e o layout (View). Desta forma,
alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser
reorganizados sem alterar o layout.

O Padrão MVC divide a aplicação em 3 camadas independentes: Model,


View e Controller, permitindo que o mesmo aplicativo possa ser visualizado através
de várias interfaces.

Figura 1 – Padrão MVC

Um diagrama simples exemplificando a relação entre Model, View e


Controller. As linhas sólidas indicam associação direta e as tracejadas indicam
associação indireta.

 Camada de Lógica da Aplicação (Model): Modela os dados e o


comportamento por trás do processo de negócio. Preocupa-se apenas
com o armazenamento e geração dos dados;
 Camada de Apresentação (View): Inclui os elementos de exibição no
cliente: HTML, XML, Applets, MIDlets. É usada para receber a entradas
de dados e apresentar o resultado;
16

 Camada de Controle (Controller): Interpreta as ações do usuário e as


mapeia para chamadas do modelo. É responsável pelo fluxo da
aplicação.

Ainda que existam diferentes formas de MVC, o controle de fluxo geralmente


funciona como a descrição abaixo:

1. O usuário interage com a interface de alguma forma (por exemplo, o


usuário aperta um botão);
2. O Controller manipula o evento da interface do usuário através de uma
rotina pré-escrita;
3. O Controller acessa o Model, possivelmente atualizando-o de uma
maneira apropriada, baseado na interação do usuário (por exemplo,
atualizando os dados de cadastro do usuário);
4. Algumas implementações de View utilizam o Model para gerar uma
interface apropriada (por exemplo, mostrando na tela os dados que foram
alterados juntamente com uma confirmação). O View obtém seus
próprios dados do Model. O Model não toma conhecimento direto da
View;
5. A interface do usuário espera por próximas interações, que iniciarão o
ciclo novamente.

A arquitetura MVC trouxe enormes benefícios para o desenvolvimento de


aplicações e logo surgiram vários frameworks que a implementaram. Estes
frameworks sugiram com o objetivo de facilitar a construção de aplicações, tentando
minimizar o trabalho repetitivo, melhorando a produtividade do desenvolvedor,
permitindo que ele se concentrasse mais na lógica de negócio de sua aplicação.

Na linguagem de programação Java um dos frameworks de mais sucesso


que utiliza o padrão MVC é o JSF (JavaServer Faces) que acabou tornando-se um
padrão adotado pelo mercado, presente na especificação Java EE e de fácil
integração com diversos outros frameworks do mercado.
17

Na linguagem de programação PHP existe muitos frameworks com o padrão


MVC, um desses frameworks é o CakePHP que tem uma grande aceitação pelos
desenvolvedores PHP.
18

4 – CAKEPHP

O framework CakePHP foi criado em 2005 por Michal Tatarynowicz quando


o framework Ruby on Rails ganhou popularidade.

Baseado no Ruby on Rails o CakePHP é um framework de desenvolvimento


rápido para PHP que fornece uma arquitetura extensível para desenvolvimento,
manutenção, e distribuição de aplicações. Usando design patterns conhecidos como
MVC e ORM com convenção sobre o paradigma da configuração.

O CakePHP usa convenções ao invés de configurações, tentando assim


reduzir o custo do desenvolvimento e ajudar os desenvolvedores a escreverem
menos código. A idéia principal é ser um framework estruturado que permita os
usuários PHP de todos os níveis, desenvolver aplicações Web robustas sem perda
de flexibilidade.

O framework CakePHP utiliza o padrão MVC(Modelo-Visualização-


Controlador), porém possui também classes e objetos adicionais que tem como
objetivo proporcionar extensibilidade e reuso, para que possam adicionar
funcionalidades à base MVC das aplicações. Componentes, Behaviors e Ajudantes
são classes que proporcionam extensibilidade e reuso para adicionar
funcionalidades à base MVC das aplicações.

4.1 - Estrutura Funcional do CakePHP

Figura 2 – Estrutura Funcional do CakePHP


19

4.1.1 - Extensões de controlador

O Componente (Component) é a classe que ajuda na lógica do controlador,


quando se possui a mesma lógica e quer compartilhar entre controladores (ou
aplicação) ao invés de escrever um método em cada controlador que utiliza esta
lógica, pode-se criar um componente que empacote esta funcionalidade e seja
compartilhado entre os controladores.

Controladores também são equipados com callbacks. Estes callbacks estão


disponíveis para que você possa utilizar, apenas se você precisar inserir uma lógica
entre operações do núcleo do CakePHP. Os callbacks disponíveis incluem:

 beforeFilter(): executado antes de qualquer ação do controlador;


 beforeRender(): executado depois da lógica do controlador, mas antes da
visão ser renderizada;
 afterFilter(): executado depois de todas as lógicas do controlador,
incluindo a renderização da visão;
 afterRender(): não há diferença entre afterRender() e afterFilter(), exceto
que você tenha feito uma chamada manualmente para render() no seu
método do controlador e tenha incluído alguma lógica depois dessa
chamada.

4.1.2 - Extensões de visão

O Ajudante (Helper) é a classe que ajuda na lógica da visão, assim como o


componente ajuda o controlador, os ajudantes permitem a apresentação lógica ser
acessada e compartilhada entre as visões. Um dos ajudantes bastante importante é
o AjaxHelper, com ele se faz requisições AJAX dentro das visões.

A maioria das aplicações tem partes do código que são usados


repetidamente nas visões. CakePHP facilita o reuso de código na visão com a
utilização de layouts e elementos (elements). Por padrão, toda visão é renderizada
por um controlador seguindo algum layout. Os elementos são como pequenos
trechos de código necessários que podem ser reutilizados em diversas visões.
20

4.1.3 - Extensões de modelo

Assim como as outras extensões, os Behaviors funcionam do mesmo modo,


adicionando funcionalidades entre os modelos. Com ele, por exemplo, podemos
adicionar o modelo Usuário como comportamento de árvore e ganhar
funcionalidades para remover, adicionar e alterar nos em sua estrutura de árvore
fundamental.

Os modelos também são suportados por outra classe chamada DataSource.


DataSources são abstrações que permitem os modelos manipularem diferentes tipos
de dados consistentemente. Enquanto a principal fonte de dados numa aplicação
CakePHP é via banco de dados, você pode escrever DataSources adicionais que
permitem seu modelo representar um feed RSS, arquivo CSV, entidades LDAP ou
eventos iCal. DataSources permite associar registros de diferentes fontes, ao invés
de limitar em joins do SQL, DataSources permitem você chamar seu modelo de
LDAP que está associada a vários eventos iCal.

Assim como nos controladores os modelos têm recursos de callback como:

 beforeFind();
 afterFind();
 beforeValidate();
 beforeSave();
 afterSave();
 beforeDelete();
 afterDelete().

Os nomes desses métodos devem ser descritivos o bastante para que saiba
o que eles fazem.
21

4.1.4 - Extensões de aplicação

Tanto os controladores, ajudantes e modelos têm uma classe pai que pode
ser usada para definir modificações na aplicação. AppController (localizado em
'/app/app_controller.php'), AppHelper (localizado em '/app/app_helper.php') e
AppModel (localizado em '/app/app_model.php'), esse são os lugares ideais para
colocar métodos que precisam ser acessados entre todos os controladores,
ajudantes e modelos.

Embora não sejam classes ou arquivos, as rotas definem regras na


requisição feita para o CakePHP. As definições das rotas definem como o CakePHP
deve mapear uma URL para um método do controlador. O behavior padrão assume
que a URL '/controller/action/var1/var2' mapeia para Controller::action($var1, $var2),
mas podemos usar rotas para personalizar URLs e como elas devem ser
interpretadas pela sua aplicação.

Alguns recursos da aplicação podem ser empacotados com mérito. Um


plugin é um pacote de modelo, controlador e visão que realiza um objetivo específico
que pode abranger vários aplicativos. Um sistema de gestão de usuários ou um blog
simplificado podem ser bons exemplos de plugins para CakePHP.

4.2 - Estrutura de Arquivos e Diretórios do CakePHP

 app;
 cake;
 vendors;
 plugins;
 htaccess;
 index.php;
 README.

A pasta app e onde fica os arquivos da aplicação.


22

A pasta cake é onde fica o núcleo do CakePHP.

A pasta vendors é onde encontrasse as bibliotecas PHP desenvolvidas por


terceiros que venham ser usadas junto com a aplicação desenvolvida com o
CakePHP.

4.2.1 - Estrutura do diretório app

 config: Contém os arquivos de configuração. Detalhes das conexões ao


banco de dados, bootstrapping, arquivos de configuração do núcleo e
outros devem ser armazenados aqui;
 controllers: Contém os controladores da aplicação e seus componentes;
 locale: Guarda os arquivos com as strings para internacionalização;
 models: Contém os modelos, behaviors e datasources da aplicação;
 plugins: Contém os pacotes de plugins;
 tmp: Armazena os arquivos temporários. Os dados atuais da aplicação
são armazenados conforme configurado no CakePHP, mas esta pasta
normalmente é usada para guardar a descrição dos modelos, logs e
outras informações, como as das sessões;
 vendors: Aplicativos e bibliotecas de terceiro;
 views: Arquivos de apresentação: elementos, páginas de erro, ajudantes,
layouts e arquivos de visões;
 webroot: No modo de produção, esta pasta deve servir como a pasta raiz
da aplicação. Dentro desta pasta são guardados os arquivos públicos,
como estilos CSS, imagens e arquivos de JavaScript.

4.3 - Convenções no CakePHP

As convenções do CakePHP foram criadas para facilitar o processo de


manutenção de uma aplicação. Convenções também fazem com que o sistema fique
uniformemente desenvolvido utilizando boas práticas de desenvolvimento,
permitindo que outros desenvolvedores o trabalhem mais facilmente. Apesar da
comunidade do CakePHP sugerir há utilização de convenções enquanto desenvolve
23

em CakePHP, muitos desses princípios são facilmente sobrescritos, algo que


especialmente acontece quando trabalha-se com sistemas legados.

Nomeando os pedaços da aplicação usando as convenções do CakePHP,


ganhasse funcionalidades sem amarras de configuração. Abaixo um exemplo que
vincula as associações:

 Tabela no banco de dados: 'people';


 Classe do modelo: 'Person', encontrada em /app/models/person.php;
 Classe do controlador: 'PeopleController', encontrado em
/app/controllers/people_controller.php;
 Template da visão: Encontrado em /app/views/people/index.ctp.

Usando estas convenções, CakePHP sabe que a requisição para


http://www.exemplo.com.br/people/ mapeia para a chamada da função index() do
PeopleController, onde o modelo Person é automaticamente disponibilizado (e
automaticamente associado à tabela 'people' no banco de dados), e renderiza isso
para o arquivo. Nenhumas destas relações foram configuradas por qualquer meio
que não seja através da criação de classes e arquivos que você precise criar em
algum lugar.

4.4 - Validações de Dados

A validação dos dados é uma das mais importantes partes de qualquer


aplicação, elas fazem com que os dados em um Model respeitem as regras da
aplicação. O Cake PHP possui recursos que ajudam no desenvolvimento das regras
de validações, a suporte as regras mais simples como também para regras mais
complexas. Há vários aspectos diferentes no processo de validação, o primeiro
passo para a validação de dados, é a criação de regras de validação no seu Model,
para isso é necessário usar a array Model::validate na definição do módulo, como
mostra o exemplo:

<?php
class Usuario extends AppModel {
24

var $name = 'Usuario';


var $validate = array();
}
?>

No exemplo acima, a array $validate foi adicionada ao Model Usuario, mas a


array ainda não contém nenhuma regra de validação. Assumindo que a tabela de
usuários já tenha os campos de login, senha, email e data de nascimento o exemplo
abaixo mostra algumas regras de validação simples para serem aplicadas à esses
campos:

<?php
class Usuario extends AppModel {
var $name = 'Usuario';
var $validate = array(
'login' => 'alphaNumeric',
'email' => 'email',
'dataNascimento' => 'date'
);
}
?>

Este exemplo mostra como as regras de validação podem ser adicionadas a


campos do model. Para o campo de login, somente letras e números serão aceitos,
o email tem de ser válido, e a data de nascimento deve ser uma data válida.
Definindo regras de validação o CakePHP mostra as mensagens de erro nos
formulários automaticamente, se os dados não seguirem as regras.
O CakePHP possui várias regras de validação, algumas das regras "de
fábrica" lhe permitem verificar as formatações de e-mails, URLs, e números de
cartões de crédito. O exemplo abaixo demonstra a utilização dessas fábricas do
CakePHP.

<?php
class Usuario extends AppModel {
var $name = 'Usuario';
var $validate = array(
'login' => array(
'alphanumeric' => array(
'rule' => 'alphaNumeric',
'required' => true,
'message' => 'Letras e números somente'
),
'between' => array(
'rule' => array('between', 5, 15),
'message' => 'Entre 5 e 15 caracteres'
)
25

),
'senha' => array(
'rule' => array('minLength', '8'),
'message' => 'Mínimo de 8 caracteres'
),
'email' => 'email',
'dataNascimento' => array(
'rule' => 'date',
'message' => 'Insira uma data válida',
'allowEmpty' => true
)
);
}
?>

Neste exemplo duas regras de validação foram definidas para o login, ele
deve conter apenas letras e números e o tamanho deve ter entre 5 e 15 caracteres.
O campo senha deve ter no mínimo 8 caracteres. O email deve ser um endereço de
email válido, e o campo data de nascimento deve ser uma data válida. E também
foram definidas mensagens personalizadas para que o CakePHP que serão
mostradas para o usuário quando as regras definidas falharem.

Como foi mostrado no exemplo acima, um único campo pode haver múltiplas
regras de validação. No CakePHP há três diferentes formas de definir regras de
validação: arrays simples, regra única por campo, e múltiplas regras por campo.

No cakePHP é possível criar regras customizadas de validações utilizando


expressão regular ou métodos personalizados.
Exemplo de validações com expressão regular:

var $validate = array(


'login' => array(
'rule' => array('custom', '/[a-z0-9]{3,}$/i'),
'message' => 'Apenas letras e números, mínimo de 3 caracteres'
)
);

O exemplo acima verifica se login contem apenas letras e números, com o


mínimo de três caracteres.

Exemplo de validações com métodos personalizados:

<?php
class Usuario extends AppModel {
var $name = 'Usuario';
26

var $validate = array(


'promotion_code' => array(
'rule' => array('limitDuplicates', 25),
'message' => 'Esse código promocional já foi usados muitas vezes.'
)
);

function limitDuplicates($data, $limite) {


$quantidade_existente = $this->find('count', array('conditions' => $data, 'recursive' => -1));
return $quantidade_existente < $limite;
}
}
?>

No exemplo acima é necessário garantir que um código promocional possa


ser usado apenas 25 vezes, assim foi adicionado um método personalizado de
validação.

4.5 - Teste no CakePHP

A partir da versão 1.2, o CakePHP passou a dar suporte a um intuitivo


framework de testes embutido dentro do próprio CakePHP. Este framework de testes
é uma extensão do SimpleTest para PHP.
O framework de testes do CakePHP dá suporte a dois tipos de testes. Sejam
Testes Unitários, em que você testa pequenas partes de seu código, tais como um
método dentro de um componente ou uma action em um controller. O outro tipo de
testes suportado é o Teste Funcional (Web Test), em que você automatiza o
trabalho de testar sua aplicação navegando nas páginas, preenchendo formulários,
clicando em links e assim por diante.

4.6 - Componentes Principais

CakePHP tem alguns acessórios para os componentes. Eles fornecem uma


saída para as tarefas mais freqüentes.
27

Nome Descrição
O Acl componente fornece de maneira fácil relação entre acesso
Acl
de controle entre banco de dados e sistema.
O auth componente fornece de maneira fácil o uso de
autenticação no sistema com variedades, tais como chamadas
Auth
de retorno de controller, Acl, ou chamadas de retorno de
Objetos.
O componente da sessão fornece um envoltório independente
Session
do armazenamento às sessões do PHP.
O request handler permite que você filtre as requisições de seus
RequestHandler visitantes e informe sua aplicação sobre os tipos favoráveis e as
informações pedidas.
O security componente permite que você ajuste uma segurança
Security
mais alta e controle a autenticação de HTTP.
Uma relação usada para emitir email usando de diversos
Email
agentes de transferência de email incluindo php mail() e smtp.
O cookie componente comporta-se de forma similar ao
Cookie SessionComponent que fornece um envoltório para o apoio
nativo do cookie.
Tabela 1 – Componentes Principais CakePHP

4.7 - Behaviors Principais

Behaviors adicionam funcionalidades extras a os modelos. O CakePHP já


vem com alguns behaviors inclusos tais como ACL, Tree e Containable.

4.7.1 - ACL behaviors

Lista de Controle de Acesso ou ACL lida com dois conceitos principais:


coisas que querem coisas inúteis, e coisas que são desejadas. No ACL, essas
coisas são na maioria das vezes usuários que pretendem usar funcionalidades são
chamados acesso de requisição de objetos ou AROs. Coisas no sistema que são
desejadas na maioria das vezes ações ou dados são chamados de controle de
acesso de objetos ou ACOs. As entidades são chamadas objetos porque algumas
vezes a requisição de objetos não é uma pessoa. Às vezes é necessário limitar o
28

acesso a certos controladores do CakePHP, quando é necessário iniciar a lógica em


outras partes da sua aplicação. ACOs pode ser qualquer coisa que você queira
controlar, de uma action de uma controlador ou até um web service.

 ACO: Controle de acesso de objetos - Qualquer coisa que é necessária;


 ARO: Requisição de acesso a objetos - Qualquer coisa que necessita de
algo.

Essencialmente, ACL é o que é usado para decidir quando um ARO quer ter
acesso a um ACO. O AclBehavior possibilita a conexão automática dos modelos
com suas tabelas Acl (Lista de Controle de Acesso). Seu uso necessita de uma
implementação do método parentNode() em seu modelo. AclBehavior pode ser
usado para criar ACOs(Controle de Acesso a Objetos) ou AROs(Acesso de
Requisição de Objetos).

ACOs cria um link do objeto diretamente ao registro na sua base de dados,


especificando um nome de modelo e um valor de chave estrangeira.

AROs é usada quando um objeto não tem uma relação direta com o registro
em sua base de dados, podendo fornecer um álias para o objeto.
Qualquer modelo pode ser um Object Request Access, mas normalmente
ele é ou o modelo do usuário ou um modelo de grupo que a autorização é feita.

4.7.1.1 - Utilização básica

É preciso incluir o comportamento e criar uma função chamada parentNode.


Isso é o mínimo necessário para usar AclBehavior:

<? Php
Usuario class extend AppModel {
var $ name = 'Usuario';
var $ actsAs = array ('Acl');

parentNode function () {
}
29

}>

A função parentNode é usada quando você tem em cascata, ou herdado


permissões, por exemplo, um modelo de Grupo. A função parentNode deve retornar
o id do modelo pai (não o id do pai Aro). Normalmente, este será o parent_id do
modelo, se estiver usando a convenção padrão para as árvores no CakePHP, como
mostra o exemplo abaixo:

<? Php
Grupo class extend AppModel {
var $ name = 'Grupo';
var $ actsAs = array ('Acl');

parentNode function () {
if (! $ this-> id) {
return null;
}

$data = $ this-> read ();


if (! $ data ['grupo'] ['parent_id']) {
return null;
Else {}
return $ data ['grupo'] ['parent_id'];
}
}
}
?>

Dessa forma o modelo agora está associado com uma entrada de AROs na
tabela do banco de dados.

4.7.2 - Containable

Uma nova adição ao core do CakePHP 1.2 é o ContainableBehavior, este


behavior permite filtrar e limitar operações de pesquisa dos Models. Usar o
Containable irá ajudar a reduzir o desgaste desnecessário do banco de dados,
aumentando a velocidade e o desempenho global do aplicativo. A classe também irá
30

ajudar a pesquisar e filtrar os dados para os usuários de uma forma limpa e


consistente.

O Containable permite racionalizar e simplificar as operações com


associações dos Models. Ele pode funcionar temporariamente ou permanentemente
alterando as associações dos modelos. O Containable é muito importante quando o
modelo possui associações complexas. Ao se usar o método contain(), o primeiro
argumento do método contain() aceita o nome ou um array de nomes do models que
se quer manter na operação de busca. Por exemplo, em um blog, para recuperar
todos os posts e suas respectivas tags sem as informações de comentários, pode
ser feito como os exemplos abaixo:

$this->Post->contain('Tag');
$this->Post->find('all');

Ou pode ser feitos dessa forma:

$this->Post->find('all', array('contain' => 'Tag'));

4.7.3 - Tree (Árvore)

É comum necessitar exibir dados hierarquicamente de alguma tabela do


banco de dados. Exemplos de tais dados podem ser categorias com subcategorias,
com diversos níveis, dados relativos a um sistema de menu com multiníveis ou
assim como uma representação de hierarquia, como é utilizado para armazenar os
objetos do ACL.

Para pequenas árvores de dados, ou quando os dados possuem apenas


alguns níveis, é simples adicionar campos como parent_id, e utilizar esse campo
para determinar o parente de dados, assim conseguindo exibir em uma estrutura
hierárquica. Bundled com o CakePHP, no entanto, provem um poderoso behavior
que permite usar os benefícios do MPTT logic.

Para usar o Tree behavior, sua tabela da base de dados precisa dos três
campos que estão listados a seguir (todos são inteiros):
31

1. Pai: nome do campo padrão é parent_id, usado para armazenar o id do


objeto pai;
2. Esquerda: nome do campo padrão é lft, usado para armazenar o valor da
esquerda da atual linha.
3. Direita: nome do campo padrão é rght, usado para armazenar o valor da
direita da atual linha.

Caso o desenvolvedor esteja acostumado com a lógica MPTT, irá se


perguntar o porquê de haver um campo pai, simplesmente porque é mais fácil fazer
determinadas tarefas se existir um link para o pai armazenado na base de dados,
como, por exemplo, quais filhos estão ligados diretamente a um item pai.

4.8 - Helpers Principais

Helpers (Ajudantes) são classes parecidas com componentes para a


camada de apresentação (view) da aplicação. Eles contêm lógicas de apresentação
que são compartilhadas entre muitos views, elementos ou layouts.

4.8.1 - AjaxHelper

O AjaxHelper utiliza as populares bibliotecas Javascript Prototype e


script.aculo.us para operações Ajax. Para usar o AjaxHelper, é necessário que a
versão atual destas bibliotecas Javascript (obtidas a partir de www.prototypejs.org e
http://script.aculo.us) estejam presentes na pasta /app/webroot/js/. Além disso,
devem-se incluir as bibliotecas Javascript Prototype e script.aculo.us em todos os
layouts ou views que utilizarem funcionalidade do AjaxHelper.

É necessário incluir os helpers Ajax e Javascript nos controllers que iram


utilizar o AjaxHelper:

class WidgetsController extends AppController {


var $name = 'Widgets';
var $helpers = array('Html','Ajax','Javascript');
32

Uma vez que incluído o JavascriptHelper no controller, pode-se usar o


método link() do helper javascript para incluir as bibliotecas Prototype e
Scriptaculous:

echo $html->link('prototype');
echo $html->link('scriptaculous');

Dessa forma para utilizar o AjaxHelper na view bastar utilizar a linha de


comando: $ajax->whatever();.

Se o componente RequestHandler for incluído no controller, então o


CakePHP poderá aplicar automaticamente o layout Ajax quando uma ação for
requisitada via AJAX.

class WidgetsController extends AppController {


var $name = 'Widgets';
var $helpers = array('Html','Ajax');
var $components = array('RequestHandler');
}

4.8.2 - FormHelper

O FormHelper é uma das novidades na versão 1.3 do CakePHP. A maior


parte do trabalho relativo à criação de formulários agora pode ser feita por esta nova
classe, no lugar dos (agora obsoletos) métodos do HtmlHelper. O FormHelper foca
na criação rápida de formulários, possibilitando validação de dados, atribuição de
valores de campos e layout. O FormHelper também é flexível com ele quase todo o
trabalho pode ser feito automaticamente, ou pode-se usar os métodos específicos
para ter apenas o que é necessário.

O primeiro método necessário para começar a usar o FormHelper é o


create(). Este método especial retorna uma tag de abertura de formulário HTML.
33

create(string $model = null, array $options = array())

Todos os parâmetros são opcionais, se o create() for chamado sem nenhum


parâmetro, ele assume que está criando um formulário que submete para o
controller atual por meio de uma action chamada add() ou edit(). O método padrão
para submissão de formulários é o POST. A tag form também é retornada com um
DOM ID. O ID é gerado a partir do nome do modelo e do nome do controller, no
formato CamelCase. Se chamarmos create() dentro de uma view do
UsuarioController, veremos uma saída semelhante à esta no código renderizado da
view:

<form id="UserAddForm" method="post" action="/users/add">

O FormHelper também inclui um método end() que completa a marcação do


formulário. Normalmente, o end() gera apenas a tag form de fechamento, mas o
end() também pode incluir campos escondidos do formulário que possam ser
necessários na lógica da aplicação.

<?php echo $form->create(); ?>


<!-- Conteúdo do formulário aqui -->
<?php echo $form->end(); ?>

Se uma string form informada como primeiro parâmetro para o método end(),
o FormHelper vai gerar um botão de submit com o nome correspondente à string
informada.

Com o FormHelper pode-se criar automaticamente campos no formulário


baseado no modelo. O principal método é o input(), este método irá
automaticamente inspecionar o campo do modelo fornecido e criar uma entrada
apropriada para esse campo, conforme mostra a tabela abaixo:

input(string $fieldName, array $options = array())


34

Tipo da Coluna Campo criado no Formulário


string (char, varchar, etc.) Text
Boolean, tinyint(1) Checkbox
Text Textarea
text, password, passwd, e psword Password
Date Selects - day, month, e year
Selects - day, month, year, hour, minute,
Datetime, timestamp
e meridian
Time Selects - hour, minute e meridian
Tabela 2 – FormHelper: Tipos Colunas / Campos Formulário

Por exemplo, supondo-se que o modelo Usuario inclui campos para um


nome de usuário (varchar), senha (varchar), data nascimento (datetime) e
observações (texto). Pode ser usado o input () método do FormHelper para criar
entradas apropriadas para todos estes campos do formulário, conforme mostra o
exemplo abaixo:

<?php echo $this->Form->create(); ?>


<?php
echo $this->Form->input('nome');
echo $this->Form->input('senha');
echo $this->Form->input('dataNascimento');
echo $this->Form->input('observacao');
?>
<?php echo $this->Form->end('Add'); ?>
Dessa forma será inserido no formulário os campos apropriados para o
modelo conforme tabela mostrada anteriormente.

O restante dos métodos disponíveis no FormHelper são para criar elementos


específicos de formulários. Muitos desses métodos também fazem uso de um
segundo parâmetro especial de opções. Nesse caso, o parâmetro $option é usado
para especificar elementos e atributos HTML (como o valor ou o id do DOM do
elemento do formulário).

<?php echo $form->text('nome', array('class' => 'users')); ?>


35

A saída na view será:

<input name="data[Usuario][nome]" type="text" class="users" id="UsuarioNome" />

O FormHelper é uma das classes mais utilizadas no CakePHP, e teve


diversas melhorias com as novas versões do CakePHP.

4.8.3 - CacheHelper

O helperCache ajuda a manter caches de todo o conteúdo de layouts e


views, economizando o tempo da obtenção de dados. O cache de views no
CakePHP armazena temporariamente o código renderizado dos layouts e views
usando o mecanismo de armazenamento definido. Deve-se atentar que o
helperCache funciona de forma diferente de outros helpers. Ele não possui métodos
a serem chamados diretamente. Ao invés disso, uma view é marcada com tags de
cache indicando quais blocos de conteúdo não devem ser guardados em cache.

Quando uma URL é requisitada, o CakePHP verifica se a string da


requisição já está em cachê, Se já estiver, o restante do processo de expedição da
URL ("dispatch") é ignorado. Quaisquer blocos nocache são processados
normalmente e a view é então servida. Isto cria uma grande economia de tempo de
processamento para cada requisição à URL em cache uma vez que um mínimo de
código é de fato executado. Se o CakePHP não encontrar uma view no cache ou se
o cache para aquela view já estiver expirado, ele continua o processo da requisição
normalmente.
36

5 - JSF (JAVASERVER FACES)

O JavaServer Faces é a especificação para um framework de componentes


para desenvolvimento web em Java. Essa especificação foi definida por meio do
Java Community Process (JCP), que é entidade que tem como objetivo especificar a
evolução linguagem Java de acordo com o interesse do mercado não apenas da
Sun, criadora da linguagem Java.

No caso do JavaServer Faces, o fato de ser uma especificação do JCP


significa que grandes empresas como Apache, BEA System, EDS, EMC Fujitsu,
Hewlett-Packard, IBM, Macromedia, Novell, Oracle, Siemens e Sun participaram na
definição do JavaServer Faces e aprovaram sua especificação. Isso torna o JSF
imediatamente um padrão de mercado. O Fato de ser uma especificação formal e
segura permite que essas empresas e outras que se interessarem invistam na
tecnologia e desenvolvam ferramentas e componentes para desenvolvimento web
com JSF. O resultado disso pode ser facilmente percebido com as inúmeras
ferramentas e componentes disponíveis no mercado para se trabalhar com JSF. O
JSF possui as seguintes partes:

 Um conjunto e componentes pré-fabricados de IU (interface de usuário);


 Um modelo de programação orientado a eventos;
 Um modelo de componentes que permite a desenvolvedores
independentes fornecerem componentes adicionais.

Alguns componentes do JSF são simples, como campos de input e botões,


enquanto outros são bastante sofisticados, como, por exemplo, tabelas de dados e
árvores.
37

5.1 - MVC no JSF (JavaServer Faces)

5.1.1 - Controller

A camada controle é composta por: um servlet chamado FacesServlet, por


um conjunto de manipuladores de ações, arquivos de configuração e observadores
de eventos. O FacesServlet é responsável pelas requisições da web e seu
redirecionamento para o modelo, bem como pelo envio da resposta. Os arquivos de
configuração são responsáveis por realizar mapeamentos e associações de ações e
pela definição das regras de navegação. Os manipuladores de eventos se
responsabilizam por receber os dados, que vem da camada de visualização, acessar
o modelo e então devolver o resultado para o FacesServlet.

5.1.2 - Model

O modelo representa os objetos de negócio e executa uma lógica de


negócio ao receber os dados vindos da camada de visualização.

5.1.3 - View

A visualização é composta por componentes trees ou UI (User Interface),


tornando possível unir um componente ao outro para formar interfaces com um grau
de complexidade maior. Na figura abaixo, pode ser verificado como funciona a
tecnologia JSF para as UIs.

Figura 3 – Tecnologia JSF para UIs


38

5.2 - Serviços Importantes do Framework JSF (JavaServer Faces)

Todas as aplicações em software permitem que os usuários manipulem


certos dados, como carrinhos de compras virtuais, itinerários de viagens ou
quaisquer outros dados necessários para um determinado contexto. Estes dados
são chamados de modelos em seu estúdio, um desenvolvedor de software produz
visões do modelo de dados. Em uma aplicação web, o HTML (ou alguma tecnologia
de renderização semelhante) é usado para pintar estas visões.

O JSF conecta a visão ao modelo, um componente de visão pode ser ligado


a uma propriedade bean de um objeto modelo, como por exemplo:

<h:inputText value=”#{user.name}”/>

Além disso, o JSF opera como o controlador que reage ao usuário,


processando eventos de ação e de mudança de valores e roteando-os para o código
que atualiza o modelo ou a visão. Por exemplo, invocar um método que verifica se o
usuário está autorizado a fazer login. Como mostra o exemplo abaixo:

<h:commandButton value=”Login” action=”#{user.check}” />

Ao clicar no botão e enviar o formulário ao servidor, a implementação JSF


invoca o método check no bean user. Esse método pode realizar ações arbitrárias
para atualizar o modelo e retornar a ID de navegações da próxima página a ser
exibida.

Assim, o JSF implementa a clássica arquitetura MVC. A tabela abaixo


mostra os termos mais importantes do JSF.

Termo Descrição
Componente UI (também Um objeto sem estado de conversação
chamado de control ou associado, mantido no servidor, que
simplesmente componente) fornece uma funcionalidade específica
para interagir com um usuário final.
39

Componentes UI são JavaBeans com


propriedades, métodos e eventos. Elas
são organizadas em uma estrutura, que
é uma árvore de componentes
geralmente apresentados como uma
página.
Renderizador Responsável por exibir um componente
da UI e transformar uma entrada do
usuário em um valor do componente.
Renderizadores podem ser projetados
para funcionar com um ou mais
componentes UI, um componente UI
pode ser associado a diversos
renderizadores.
Validador Responsável por garantir que o valor
digitado por um usuário é aceitável. Um
ou mais validadores podem ser
associados com um componente da UI.
Backing beans Uma especialização do JavaBeans que
coleta valores a partir de componentes
da UI e implementam métodos dos
eventos dos ouvintes. Eles também
podem possuir referências a elementos
da UI.
Conversor Converte o valor de um componente
para String e também executa a
operação reversa. Um componente UI
pode ser associado com apenas um
conversor.
Eventos e ouvintes(listeners) JSF usa o modelo JavaBean de
evento/ouvinte(também usado pelo
Swing). Componentes UI (e outros
objetos) geram eventos e ouvintes
40

podem ser registrados para lidar com


esses eventos.
Mensagens Informações que são exibidas de volta
para o usuário. Em qualquer parte da
requisição (backing beans, validadores,
conversores, e assim por diante)
mensagens de erro podem ser geradas
ou podem ser exibidas informações
para o usuário.
Navegação A capacidade de passar de uma página
para a próxima. JSF possui um
poderoso sistema de navegação que é
integrado com os ouvintes dos eventos.
Tabela 3 – Termos Mais Importantes do JSF

5.2.1 - Componentes UI

No JavaServer Faces os componentes UI, possui a função de interação com


o usuário final da aplicação. Como são criados sobre a arquitetura JavaBeans,
possuem propriedades, métodos e eventos e suporte das IDE, suporte este que
facilita muito o desenvolvimento, permitindo ao desenvolvedor ter acesso a todas as
características do componente.

Componentes UI podem ser um conjunto de subcomponentes que permite


que o desenvolvimento se torne rápido e muito mais fácil, pois este componente irá
utilizar todos os recursos já incluídos nos outros componentes.

Um exemplo prático seria a criação de um componente de contato, que


poderia ser composto por campos de entrada para os dados como nome, email,
descrição, cidade e por uma combo para seleção do estado.

Para o desenvolvedor deste componente, toda as tarefas de


desenvolvimento dos elementos básicos como entrada de texto e combos, já estará
41

feita, permitindo que o desenvolvedor foque seu desenvolvimento arquitetura de seu


componente.

Analisando a utilização desse componente por outro desenvolvedor no


futuro, ele irá abstrair todo o trabalho que foi feito para a construção do mesmo, e
concentrará seus esforços apenas na construção da página.

Esta arquitetura, além de permitir a reutilização de código, permite também


que o trabalho seja mais bem dividido, permitindo que um desenvolvedor se
especialize em uma parte do trabalho. Para o desenvolvedor que utilizará o
componente pronto, não haverá o pré-requisito que o mesmo possua domínio em
HTML e Javascript. Ele precisará apenas saber quais as propriedades deste
componente, para poder fazer o uso do mesmo.

Os componentes possuem uma separação entre seu funcionamento e sua


aparência que é definida pela maneira como ele é renderizado. Esta separação
permite a modificação da aparência, sem modificar seu comportamento e
funcionamento, permitindo uma flexibilidade muito grande, pois uma aplicação pode
ter sua aparência toda mudada sem precisar modificar a maneira como os
componentes são utilizados na programação.

O framework JSF mantém uma árvore com os componentes UI, chamada de


view, que permite que cada componente lembre seus valores entre as requisições. A
view é a representação interna do JSF para a página e mantém uma estrutura
hierárquica de pai e filho. JSF possui componentes UI padronizados como Text box,
painel, label, data grid, gráfico, listbox, radio button, checkbox, etc. E outras
possibilidades como Toolbar, menu, viewer RSS, tabbed pane, file upload, etc

5.2.2 - Renderizador

Responsável por exibir um componente da UI e transformar uma entrada do


usuário em um valor do componente. Renderizadores podem ser projetados para
funcionar com um ou mais componentes UI, um componente UI pode ser associado
a diversos renderizadores. Por padrão, o JSF gera comandos para páginas HTML,
42

contudo, é fácil estender o framework JSF de modo a produzir comandos para outra
linguagem de descrição de páginas, como WML ou XUL, a varias exemplos em
livros e na Internet, que mostra como usar o JSF para se comunicar com telefones
celulares habilitados para Java ME.

5.2.3 - Backing beans

De acordo com a especificação JavaBeans, um bean Java é um


“componente reutilizável de software manipulável em uma ferramenta de
construção”. À primeira vista os beans assemelham-se aos objetos. Entretanto, eles
servem a um propósito diferente.

No contexto do JSF, beans são mais que componentes de interfaces de


usuário. Eles são usados, sempre que preciso, para ligar classes Java a páginas
web ou arquivos de configuração. Uma vez definido um bean, ele pode ser acessado
pelos componentes JSF.

Uma especialização do JavaBeans que coleta valores a partir de


componentes da UI e implementam métodos dos eventos dos ouvintes. Eles
também podem possuir referências a elementos da UI. Usualmente trabalha com
objetos do modelo para executar lógica de negócios.
Pode-se ligar um valor de componente a uma propriedade de backing bean:

<h:outputText id=“olaBeanOutput” value=“#{olaBean.valor01}”/>

Com esta associação, temos uma sincronia, caso o valor seja mudado no
componente, a propriedade do bean terá seu valor modificado e recíproca também
ocorre. Pode-se também ligar uma instância de componente a uma propriedade de
backing bean:

<h:panelGrid id=“painel” binding=“#{olaBean.painel}” columns=“20” border=“1” cellspacing=“0”/>

Isto permite que o componente seja manipulado através de código Java


dentro do backing bean.
43

5.2.4 - Escopo dos beans

Os quatro escopos permitidos são: none, request, session e application. Se


o escopo for definido como none, então o bean receberá uma nova instância a cada
vez que for referenciado. O escopo de request (requisição) tem vida curta. Ele
começa quando uma requisição TTP é submetida e termina quando a resposta é
enviada de volta ao cliente. Para uma aplicação onde às transações com o usuário
são importantes, utiliza-se o escopo session, por exemplo, para um sistema de
comércio eletrônico, que detêm um carrinho de compras virtual. O escopo
application persiste por toda a duração da execução da aplicação web. Este escopo
é compartilhado por todas as requisições e por todas as sessões de todos os
usuários, portanto, tome muito cuidado ao usá-lo.

5.2.5 - Validadores

O JSF facilita a tarefa de vincular regras de validações a campos do tipo


“este campo é obrigatório” ou “este campo deve ser número”. Obviamente e preciso
exibir mensagens de erro apropriadas quando os usuários digitam dados inválidos.

É difícil imaginar uma aplicação web que não precise fazer uma boa dose de
validações dos dados, O JSF atende a estes requisitos, tanto no que diz respeito a
fornecer validadores padrões, como oferecer um mecanismo simples para
implementar seus próprios validadores. A função principal da validação é proteger o
modelo. Como o JSF usa fases separadas para processar validadores e atualizar os
valores do modelo, isso garante que o modelo não será colocado em um estado
inconsistente se alguns dos inputs não puderem ser validados.

O JSF lida com validação de dados de três maneiras: no componente,


através de métodos de validação nos backing beans ou com classes de validação
que são chamados validadores. Na validação no componente, temos geralmente
uma validação básica como a de obrigatoriedade de um campo, ou checar se o
usuário informou uma data válida. Métodos de validação são úteis quando a
validação depende de mais um componente, ou há uma lógica mais complexa
44

envolvida e está lógica é especifica e não precisa ser compartilhada com outras
páginas.

As classes de validação são muito úteis para validações genéricas pontuais,


como checar o tamanho de uma String, ou checar se a data é menor que a data
atual. São validações pontuais e específicas que podem ser encadeadas,
adicionando mais de um validador por componente, esta abordagem é muito
eficiente e garante um reuso muito grande de código.

Exemplo com validadores padrões do JSF:

<h:inputText id=”nome” value=”#{pessoa.nome}”>


<f:validateLength minimum=5 maximum=30 />
</h:inputText>

O exemplo acima adiciona um validador a um campo texto, quando o campo


texto do formulário for enviado, o validador garante que o texto informado no campo
esteja em 5 e 30 caracteres. Quando a validação falhar os validadores geram
mensagens de erro associadas ao componente responsável pelo erro. Estas
mensagens podem ser exibidas futuramente nas páginas JSF.

Para indicar que um determinado campo do formulário e obrigatório basta


adicionar o atributo required=”true”, todas as tags de inputs do JSF dão suporte ao
atributo required. É possível combinar este atributo required como um validador
aninhado:

<h:inputText id=”nome” value=”#{pessoa.nome}” required=”true”>


<f:validateLength minimum=5 maximum=30 />
</h:inputText>

Uma outra forma de se anexar um validador a um componente consiste em


usar a tag f:validator, Para isto basta especificar a ID e os parâmetros do validador,
como mostra o exemplo abaixo:

<h:inputText id=”nome” value=”#{pessoa.nome}”>


45

<f:validator validatorId=”javax.faces.validator.LengthValidator”>
<f:attribute name=”minimum” value=”5”/>
</f:validator>
</h:inputText>

Exemplo de criação de um método validador dentro do backing bean:

public void validateEmail(FacesContext context, UIComponent toValidate, Object value) {


String email = (String) value;
if (email.indexOf('@') == -1) {
((UIInput)toValidate).setValid(false);
FacesMessage message = new FacesMessage("Email Inválido!");
context.addMessage(toValidate.getClientId(context), message);
}
}

Este método então seria utilizado dentro de uma tag JSF através do atributo
validator como abaixo:

<h:inputText id=”email”
value=”#{pessoa.email}”
validator=”#{pessoa.checkEmail}”
</h:inputText>

Caso o valor do componente inputText não seja um formato de endereço de


e-mail válido, então será adicionado uma mensagem de erro no faces context
associado ao componente para ser exibida na página JSF.

Implementar uma classe validadora customizada consiste em um processo


formado por duas etapas: a primeira etapa é criar a classe que utilize a
implementação javax.faces.validator.Validator, a segunda etapa é registrar seu
validador no arquivo de configuração do JSF o faces-config.xml, no o JSF 2.0 pode
se também registrar a classe validadora utilizando Anotações.

Exemplo classe validadora:


46

public class EmailValidator implements Validator{

private static final String EMAIL_PATTERN = "^[_A-Za-z0-9-]+(\\." +


"[_A-Za-z0-9-]+)*@[A-Za-z0-9]+(\\.[A-Za-z0-9]+)*" +
"(\\.[A-Za-z]{2,})$";

private Pattern pattern;


private Matcher matcher;

public EmailValidator(){
pattern = Pattern.compile(EMAIL_PATTERN);
}

@Override
public void validate(FacesContext context, UIComponent component,
Object value) throws ValidatorException {
matcher = pattern.matcher(value.toString());
if(!matcher.matches()){
FacesMessage msg = new FacesMessage("E-mail validation failed.", "Invalid E-mail format.");
msg.setSeverity(FacesMessage.SEVERITY_ERROR);
throw new ValidatorException(msg);
}
}
}

Esta classe validadora então seria utilizado dentro da pagina JSF através da
tag f:validator, como mostra o exemplo abaixo:

<h:inputText id=”email” value=”#{pessoa.email}”>


<f:validator validatorId=”exemplo.classeValidadora. EmailValidator”/>
</h:inputText>

5.2.6 - Conversor

Os converters tem por finalidade converter e/ou formatar objetos do tipo


Java para String e vice-versa. Obviamente todos os valores de requisição são
strings, afinal o navegador-cliente envia as strings fornecidas pelo usuário, por outro
lado aplicação web trabalha com tipos arbitrários, como int, Date, Double ou mesmo
47

outros tipos de dados mais sofisticados. Um processo de conversão transforma as


strings recebidas nestes tipos, como também faz a operação inversa.

Os valores convertidos não são imediatamente transmitidos aos beans que


formam à lógica de negócios. Ao invés disso, eles são primeiro armazenados nos
objetos componentes como valores locais, após a conversão, ocorre à validação
destes valores locais, somente após passar pelas conversões e validações os
valores são transmitidos aos beans.

Os converters são bi-direcionais o backing bean utiliza o método do


converter getAsObject() e página JSF utiliza o método getAsString().

O JSF já trás em sua biblioteca vários converters padrões, que são muito
utilizados no dia a dia de um programador como conversão de tipos: date, double,
number e etc. Ele também oferece a opção de criação de converters customizados
para cada necessidade.

Exemplo de converters padrões do JSF:

<h:inputText id=”valor” value=”#{conta.valor}”>


<f:converterNumber type=”currency” minFractionDigits=”2”/>
</h:inputText>

Anexando o converter ao campo valor, o atributo type fornece


automaticamente o símbolo de moeda e os separadores decimais, já com o atributo
minFractionDigits o configuramos para que o valor atual tenha pelo menos dos
dígitos após o ponto decimal.

<h:inputText id=”data” value=”#{conta.data}”>


<f:converterDateTime pattern=”dd/MM/yyyy” />
</h:inputText>

O exemplo acima utilize o converter padrão do JSF f:converterDateTime cujo


atributo pattern esta configurado para exibir a data no formato dia, mês e ano.
48

Um exemplo de criação de uma classe de conversão customizada e a


criação de uma converter para o objeto Cidade, a muitos cadastro em páginas na
web possuem um combo com a lista de cidades, estas cidades muitas vezes são
objetos que possuem vários atributos como id, nome, estado e pais. Dessa forma
queremos exibir na página somente o nome das cidades, porém em nosso backing
bean precisamos do objeto cidade para manipulá-lo. Para implementar a classe
customizada de conversão é necessário implementar a classe Converter e
sobrescrever seus dois métodos getAsObject e getAsString e também registrar o
converter no arquivo de configuração do JSF o faces-config.xml, ou no JSF 2.0 pode
se também registrar a classe conversora utilizando Anotações.

public class CidadeConverter implements Converter {

@Override
public Object getAsObject(FacesContext context, UIComponent component, String value) {
if (value != null && !value.isEmpty()) {
return Cidade.findById(new Long(value));
}
return null;
}

@Override
public String getAsString(FacesContext context, UIComponent component, Object value) {
if (value instanceof Cidade) {
Cidade cidade = (Cidade) value;
return cidade.getId().toString();
}
return "";
}
}

Esta classe conversora então seria utilizado dentro da pagina JSF como
mostra o exemplo abaixo:

<h:selectOneMenu id="cidade" value="#{cadastro.cidade}" converter="converterCidade">


<f:selectItems value="#{cadastro.listaCidades}"/>
</h:selectOneMenu>
49

5.2.7 - Eventos e ouvintes

Nas aplicações web, os eventos capturam a interação do usuário com os


componentes, sendo este evento algo como um simples clique em um botão ou link,
ou algo mais complicado que execute alguma regra de negócio. No JSF o a função
de lidar com esses eventos fica sobre responsabilidade de um JavaBean, usando
objetos de eventos e ouvintes e um componente pode possuir um, vários ou nenhum
ouvinte para manipular seus respectivos eventos.

O tratamento de eventos sempre foi algo complexo na programação web,


precisando o programador tratar as submissões e requisições geradas pelas ações
do usuário ao interagir com a aplicação, gerando eventos, e aplicar a lógica de
negócios correta. O JSF dá suporte a três tipos de eventos:

Tipos Eventos Descrição Eventos


Eventos de alteração de valor Os eventos de alteração de valor são
disparados por componentes de input,
como h:inputText e h:selectOneRadio,
quando o valor do componente mudar.

Eventos de ação Os eventos de ação são disparados por


componentes de comando, como
h:commandButton e h:commandLink,
quando o botão ou o link for ativado.
Eventos de fase Os eventos de fase, geralmente, são
disparados pelo ciclo de vida do JSF.
Tabela 4 – Tipo de Eventos do JSF

Para manipular eventos é preciso ter uma compreensão básica deste ciclo
de vida.
50

5.2.7.1 - Eventos do ciclo de vida

Nas aplicações JSF, as requisições são processadas pela implementação


JSF com um servlet controlador que executa o ciclo de vida do JSF. O ciclo de vida
do JSF é composto pelas seguintes fases:

1. Restaurar Apresentação;
2. Aplicar Valores de Requisição;
3. Processar Validações;
4. Atualizar Valores no Modelo;
5. Invocar Aplicação;
6. Renderizar Resposta.

A partir da fase Aplicar Valores de Requisição, a implementação JSF pode


criar eventos e adicioná-los a uma fila de eventos durante casa fase do ciclo de vida.
Depois destas fases, a implementação JSF difunde os eventos na fila para os
listeners registrados.

Os listeners de eventos podem afetar o ciclo de vida do JSF de três


maneiras:

1. Deixando o ciclo de vida ocorrer normalmente;


2. Chamando FacesContext.renderResponse() para ignorar o resto do ciclo
de vida até a fase Renderizar Resposta;
3. Chamando FacesContext.responseComplete() para ignorar por completo
o resto do ciclo de vida.

5.2.7.2 - Eventos de alteração de valor

São eventos gerados por campos de entrada de dados quando o usuário


entra como um novo valor em algum campo e um ouvinte fica responsável por este
evento.
51

Os componentes de uma aplicação web geralmente dependem uns dos


outros. Por exemplo, em um formulário com os campos estado e país, o valor do
campo estado depende do valor selecionado no campo país. É possível manter
componentes dependentes em sincronia com os eventos de alteração de valor,
estes por sua vez são disparados pelos componentes de input após a validação de
seu valor.

<h:selectOneMenu value=”#{form.pais}” onchange=”submit()”


valueChangeListener=”#{form.paisSelecionado}”>
<f:selectItems value=”#{form.listaPaises}” />
</h:selectOneMenu>

Quando o usuário seleciona um país no menu, a função submit do


JavaScript é invocada para enviar o formulário do menu que, em seguida, invoca o
ciclo de vida do JSF. Após a fase Processar Validações, a implementação JSF
invoca o método paisSelecionado do bean form. Este método altera a visão do
locale-raiz de acordo com o novo valor selecionado no campo país:

private static String US = “United States”;


public void paisSelecionado(ValueChangeEvent event) {
FacesContext context = FacesContext.getCurrentInstance();
If (US.equals(String) event.getNewValue())
Context.getViewRoot().setLocale(Locale.US);
else
Context.getViewRoot().setLocale(Locale.CANADA);
}

Como todos os listeners de alteração de valor, o listener mostrado acima é


passado como um evento de alteração de valor. O listener usa este evento para
acessar o novo valor do componente. A classe ValueChangeEvent estende
FacesEvent, ambas residentes em javax.faces.event package.

Os métodos mais usados para estas classes são:


52

API javax.faces.event.ValueChangeEvent
Métodos Descrição
Retorna o componente de input que
UIComponent getComponente()
ativou o evento.
Retorna o novo valor do componente,
Object getNewValue() depois que o valor foi convertido e
validado.
Retorna o valor anterior do
Object getOldValue()
componente.
Tabela 5 – API javax.faces.event.ValueChangeEvent

API javax.faces.event.FacesEvent
Métodos Descrição
Coloca o evento na fila para ser
void queue() entregue ao fim da fase atual do ciclo
de vida.
Retorna o identificador de fase
PhaseId getPhaseId() correspondente á fase em que o evento
será entregue.
Define o identificador e fase
void setPhaseId(PhaseId) correspondente á fase em que o evento
será entregue.
Tabela 6 – API javax.faces.event.FacesEvent

5.2.7.3 - Eventos de ação

Os eventos de ação são disparados por componentes de comando como


botões, links, etc - quando o componente é ativado. Os eventos de ação são
disparados durante a fase Invocar Aplicação, perto do fim do ciclo de vida.
Geralmente, os listeners de ação são anexados aos componentes de comando da
página, por exemplo, é possível adicionar um listeners de ação a um link, desta
forma:

<h:commandLink actionListener=”#{bean.linkAtivado}”>
53


</h:commandLink>

Os componentes de comando enviam requisição quando são ativados.


Assim, não é preciso utilizar onchange para forçar o envio do formulário. Ao ativar
um comando ou link, o formulário adjacente é enviado e a implementação JSF
dispara, em seguida, os eventos de ação.

É importante diferenciar listeners de ação de ações. As ações são


projetadas para a lógica de negócios e participam do tratamento da navegação. Já
os listeners de ação, geralmente cuidam da lógica da interface com o usuário, não
sendo responsáveis pelo tratamento da navegação. Os listeners de ação trabalham
de acordo com as ações quando uma delas precisa de informações sobre a interface
do usuário.

5.2.7.4 - Eventos de fase

A implementação JSF dispara eventos, chamados eventos de fase, antes e


depois de cada fase do ciclo de vida, que são manipulados pelos listeners de fase.
Ao contrário das mudanças de valor e dos listeners de ação, anexados a
componentes individuais, os listeners de fase são especificados em um arquivo
faces de configuração, desta forma:

<faces-config>
<lifecycle>
<phase-listener>com.corejsf.PhaseTracker</phase-listener>
</lifecycle>
</faces-config>

O código acima especifica apenas um listener, mas é possível especificar


quantos desejar. Os listeners são invocados na ordem em que forem especificados
no arquivo de configuração.

Os listeners de fase são implementados por meio da interface PhaseListener


do javax.faces.event package. Esta interface define três métodos:
54

1. PhaseId getPhaseId();
2. void afterPhase(PhaseEvent);
3. void beforePhase(PhaseEvent).

Entre algumas possibilidades de utilizações, podemos mensurar o grande


beneficio de se usar eventos de fase para identificar gargalos de desempenho em
um sistema, registrando a hora de entrada e saída de cada uma das fases do ciclo
de vida da requisição. Desde modo podemos identificar qual a fase que está
demorando mais ao ser processada. Os listeners de fase também são úteis para
aplicações que utilizam Ájax para oferecer uma experiência mais sofisticada ao
usuário.

5.2.8 - Mensagens

Em uma aplicação web é necessário o envio de mensagens de texto em


resposta às interações do usuário com a aplicação. Estas mensagens podem ter
muitas finalidades, desde meramente informativas para auxiliar o usuário, até
mensagens de alerta, informando ao usuário que o mesmo não está utilizando
corretamente o sistema.

As mensagens mais comuns são as de erro e se dividem em erros de


aplicação e erros de entrada de dados do usuário. Os erros de aplicação,
geralmente são mais graves e redirecionam para alguma página informando o
problema e pedindo para tentar novamente mais tarde, ou entrar em contato com o
suporte do sistema. Quando é um erro de entrada de dados, o comum é mostrar a
página novamente, e informar qual foi o erro, como uma data inválida, ou algum
campo requerido não preenchido.

O JSF possui o sistema de mensagens para auxiliar nestes problemas e


podem ser automaticamente geradas no idioma do usuário. Uma mensagem nada
mais é que um conjunto de dados tais como um texto resumido, um texto detalhado
e um nível de severidade que nas mensagens de erro informa a gravidade do erro.
As mensagens podem ser associadas a um componente especifico, caracterizando
55

os erros de entrada de dados ou não possuir associação e assumir o papel de uma


mensagem de erro de aplicação.

As mensagens fazem parte do sistema de validadores e conversão de tipos


de dados do JSF, e onde ocorrer um erro em alguma destas fazes, será gerada uma
mensagem.

Obviamente, é importante que o usuário possa ver as mensagens de erros


causadas por erros de validações. Para a exibição dessas mensagens devem ser
adicionadas as tags h:message sempre que houver utilização de validadores. Hoje
no mercado há muitas bibliotecas de componentes visuais que oferecem inúmeros
recursos para exibição dessas mensagens tanto para erros de validações como
conversões de dados.

Desde da versão 1.2 do JSF é possível fornecer mensagens de erro de


validações customizadas para um componente. Para isto, basta definir o atributo
validatorMessage ou requiredMessage do componente cujo valor está sendo
validado.

5.2.9 - Navegação

Em uma aplicação geralmente existem muitas páginas e de alguma maneira,


ao operar o sistema, o usuário navegará entre diversas páginas. Antes do MVC o
sistema de navegação era descentralizado, cabendo a cada página saber qual a
próxima página que será mostrada ao usuário. Este sistema descentralizado trás
alguns problemas e o mais obvio é quando se faz necessária alguma regra de
navegação, implicando na utilização de testes condicionais para decidir qual será a
próxima página.

O JSF resolveu este problema criando um controlador de navegação que


possui a responsabilidade de decidir qual será a próxima página, baseado nas ações
do usuário. Para qualquer página, um sistema de regras de navegação define como
será feita a navegação, sendo estas regras configuradas em arquivos específicos
e/ou programadas na aplicação.
56

5.3 - Ciclo de Vida do JSF

A especificação JSF define seis fases distintas, conforme demonstra a figura


abaixo. O Fluxo normal de controle é mostrado em linhas sólidas e os fluxos
alternativos, em linhas pontilhadas.

Figura 4 – Ciclo de Vida do JSF

A fase restaurar apresentação recupera a árvore de componentes para a


página requisitada, caso ele tenha sido exibida antes, ou constrói uma nova árvore
de componentes, caso esteja sendo exibida pela primeira vez. Caso a página tenha
sido exibida antes, todos os componentes são configurados para seu estado
anterior. Isto mostra que o JSF automaticamente guarda informações de formulários.
Por exemplo, quando um usuário posta dados que são rejeitados durante a
codificação, os antigos inputs são reexibidos para que o usuário possa corrigi-los.

Se a requisição não possuir os dados solicitados, a implementação JSF pula


a fase renderizar resposta. Isto acontece quando a página é exibida pela primeira
vez.

Caso contrário, a próxima fase é Aplicar valores requisitados. Nesta fase, o


JSF faz iterações sobre os objetos componentes da árvore de componentes. Cada
objeto componente verifica quais valores requisitados pertencem ao objeto em
questão e armazena-os. Além de extrair informações de requisição, a fase Aplicar
57

valores requisitados adiciona eventos a uma fila de eventos caso um botão de


comando ou link tenha sido acionado.

Na fase processar validações, a string passada é convertida para valores


locais, que pode ser um objeto de qualquer tipo, quando passa pela validação segue
seu fluxo normal, contudo quando ocorrem erros de conversão ou de validação, a
implementação JSF invoca a fase renderizar, exibindo a página atual para que o
usuário possa corrigir os erros.

Para muitos programadores, esse é o aspecto mais surpreendente do ciclo


de vida do JSF. Se um conversor ou validador falhar, a página atual é reexibida
(GEARY; HOSTMANN, 2007).

Após a validação e conversão, os valores locais armazenados são utilizados


para atualizar os beans vinculados aos componentes com segurança.

Na fase Invocar Aplicação, é executado o método action do componente


botão ou link que causou o envio do formulário. O método pode realizar
processamentos de aplicação arbitrários. Ele retorna uma string de resultado, que é
passada para o handler de navegação, que procura a página seguinte.

A fase renderizar resposta é responsável por codificar a resposta e envia-a


para o navegador, e a partir daí o ciclo se renova novamente.

5.4 - Tags Fundamentais do JSF (JavaServer Faces)

O desenvolvimento de aplicações JSF bem elaboradas, tanto a fundamental


quanto a HTML requer um bom domínio das bibliotecas de tags do JSF. A biblioteca
fundamental contém as tags que são independentes da tecnologia de renderização.
58

Tags Descrição
View Cria a visão de nível mais alto
Subview Cria uma subvisão de uma visão
Attribute Define um atributo (key/value) em seu
componente de origem
Param Adiciona um parametro subordinado a
seu componente de origem
Facet Adiciona uma faceta a um componente
actionListener Adiciona um listener de ação que define
uma propriedade
setPropertyActionListener Adiciona um listener de ação a um
componente
valueChangeListener Adiciona uma listener de mudança de
valor a um componente
phaseListener Adiciona um listener de fase à visão de
origem
Converter Adiciona um conversor arbitrário a um
componente
convertDateTime Adiciona um conversor de data e hora a
um componente
convertNumber Adiciona um conversor numérico a um
componente
Validator Adiciona um validador a um
componente
validatedateDoubleRange Valida uma range dupla(double) para o
valor de um componente
validateLongRange Valida a extensão de valor de um
componente
loadBundle Carrega um resource bundle; armazena
propriedades como um Map
Selectitems Especifica itens para um componente
select one ou select many
Selectitem Especifica um item para um
59

componente select one ou select many


Verbatim Transforma um texto contendo código
markup em um componente
Tabela 7 – Tags Fundamentais do JSF

A maior parte das tags fundamentais representa objetos que são


adicionados aos componentes:

 Atributos;
 Listeners;
 Conversores;
 Validadores;
 Facetas.

A tabela abaixo mostra as tags HTML do JSF.

Tags Descrição
Form Formulário HTML
Input Text Controle de input de texto de uma
única linha
inputTextarea Controle de input de texto de várias
linhas
inputSecret Controle de input de senha
inputHidden Campo oculto
outputLabel Rótulo para outro componente, para
fins de acessibilidade
outputLink Âncora HTML
outputFormat Igual a outputText, mas formata
mensagens compostas
outputText Output de texto de uma única linha
commandButton Botões: submit, reset ou pushbutton
commandLink Link que age como um pushbutton
Message Exibe a mensagem mais recente de um
60

componente
Messages Exibe todas as mensagens
graphicImage Exibe uma imagem
selectOneListbox Caixa de listagem para seleção de um
único item
selectOneMenu Menu para seleção de um único item
selectOneRadio Conjunto de botões de rádio
selectBooleanCheckbox Caixa de verificação
selectManyCheckbox Conjunto de caixas de verificação
selectManyListbox Caixa de listagem para seleção de
vários itens
selectManyMenu Menu para seleção de vários itens
panelGrid Tabela HTML
panelGroup Dois ou mais componentes dispostos
como um só
dataTable Controle de tabela com muitos recursos
Column Coluna em uma dataTable
Tabela 8 – Tags HTML do JSF
61

6 - COMPARAÇÕES ENTRE CAKEPHP E JSF (JAVASERVER FACES)

6.1 - Documentação

6.1.1 – JSF (JavaServer Faces)

O Java Server Faces por ser uma especificação do Java EE, possui grande
documentação disponível, a documentação é bem estruturada, facilitando assim o
estudo e a solução de problemas quando se está utilizando a tecnologia. A
documentação explica toda parte técnica e estrutural do framework, mostrando
pequenos exemplos de utilizações de cada item constante na documentação.

A documentação do JSF é toda em inglês, não disponibilizada em outros


idiomas, necessitando assim o conhecimento de leitura para entender melhor a
documentação, como o JSF é muito utilizado no Brasil a vários sites que
disponibilizam partes especificas da documentação em português.

Como se trata de um padrão de desenvolvimento para web em Java, há


vasta bibliografia disponível em livros e revistas, além de muitas apostilas
disponibilizadas pela comunidade na internet.

6.1.2 - CakePHP

A documentação do CakePHP é escrita pela comunidade e é baseada em


exemplos ao invés de termos técnicos, isso facilita no aprendizado da tecnologia,
mas faz com que se utilize muitas vezes um determinado recurso sem saber
realmente o que ele faz.

A documentação principal do framework está em inglês, mas possui versões


menos completa em português e outros idiomas. Os textos escritos em português
possuem muitos erros de ortografia. No site da documentação é possível que o
usuário efetue correções dos textos disponíveis caso encontre erros.
62

A documentação é muito limitada quando se tem um problema especifico,


sendo assim necessário recorrer a fóruns para resolver, ela baseia-se mais em
mostrar um exemplo simples de como funciona cada item.

Quase não há livros disponíveis sobre o CakePHP, o que se encontra são


apostilas escritas pela comunidade na internet.

6.2 - Curva de Aprendizagem

6.2.1 - JSF (JavaServer Faces)

O aprendizado do framework JSF não é complexo, entretanto a maior


dificuldade está em entender a linguagem por trás dele, ou seja, Java. Pessoas com
conhecimento da linguagem de programação Java terão menor dificuldade para
aprender o framework, pois conhece a linguagem base do mesmo. Já pessoas
vindas de outras linguagens de programação terão dificuldades por não conhecer os
conceitos básicos da programação Java.

A curva do aprendizado ainda é o grande vilão sobre o aprendizado e a


utilização das tecnologias Java. Muitas empresas acabam selecionando
erradamente outras tecnologias devido a este fato, como se aprendizado e
produtividade fossem requisitos funcionais da aplicação.

Não há dúvida de que ter uma equipe capacitada e produtiva é fator


fundamental para o sucesso do projeto, entretanto não fazem parte de nenhum tipo
de requisito. O sistema final deve ser entregue para o cliente na tecnologia que
suporte seus "requisitos funcionais e não-funcionais" estabelecido pelo escopo,
independentemente da capacidade ou produtividade de uma equipe de TI.

Como a tecnologia Java foi completamente concebida em cima de conceitos


e técnicas da engenharia de software, o que acontece na maioria dos casos é que o
candidato a aprender Java acaba deparando com um mundo totalmente novo e
complexo, devido à falta de uma base sólida de conhecimento sobre o assunto. Ou
seja, se uma pessoa tem conhecimentos básicos sobre assuntos relacionados com a
63

engenharia de software, com certeza não teria muitas dificuldades para aprender as
implementações que as tecnologias Java faz da mesma.

Antes de entrar em detalhes específicos de determinada tecnologia em si, o


candidato pode identificar os conceitos relacionados no contexto e procurar entendê-
los de forma prévia e separada antes de entrar na programação em si. Este caminho
se mostra muito interessante para se obter bons resultados. O ideal é entender os
conceitos básicos da tecnologia que está utilizando ir aprendendo conforme a
necessidade aparece.

O iniciante em JSF deve primeiramente entender os fundamentos base do


framework: ciclo de vida, comunicação entre managed beans, escopos de
conversação, árvore de componentes, converters, validators, phase listeners e
modelo dos componentes. Entendendo bem estes fundamentos ira ajudar muito
para um aprendizado correto do framework.

No Brasil temos inúmeras empresas que disponibilizam cursos e


treinamentos do framework JSF, inclusive demonstrando como integrá-lo com outras
tecnologias disponíveis no mercado para desenvolvimento Web com a linguagem de
programação Java.

Na Internet há muitos sites, fóruns, listas de discussões e exemplo de


códigos que facilitam o aprendizado.

6.2.2 - CakePHP

O aprendizado do framework CakePHP é sua grande vantagem para outros


frameworks para desenvolvimento web que utilizam MVC. O CakePHP leva muita
vantagem nesse quesito para outros frameworks web que utilizam a linguagem de
programação PHP, uma vez que entendido a estrutura de arquivos do CakePHP e o
modo que o mesmo trabalha a produtividade com ele é percebida rapidamente.

Como ele trabalha utilizando convenção ao invés de configuração, minimiza


muita a necessidade de vários arquivos de configurações que muitas vezes acaba
64

atrapalhando o aprendizado inicial de uma nova tecnologia, desmotivando a


continuação do aprendizado.

Como o CakePHP utiliza a linguagem de programação PHP, e a linguagem


é utilizado exclusivamente para desenvolvimento Web, os programadores que
conhecem a linguagem, não encontraram muitas dificuldades no aprendizado, já
programadores iniciantes devem primeiramente conhecer um pouco a linguagem de
programação PHP antes de iniciar o estudo do framework.

Uma dificuldade que pode ser encontrada por programadores que já


conheçam a linguagem PHP, é o fato de o CakePHP trabalhar com orientação
objeto, e que muitos desenvolvedores que utilizando o PHP ainda não conhece esse
conceito, necessitando assim um estudo prévio do uso da orientação objeto em
PHP.

6.3 - Integração com Outros Frameworks

6.3.1 - JSF (JavaServer Faces)

Um dos pontos fortes desse framework é a fácil integração com outras


ferramentas, o JSF deixa o desenvolvedor livre para usar seus recursos e também
usar recursos de outros frameworks. Essa liberdade oferecida pelo JSF soluciona
muitos problemas que ocorrem no decorrer do desenvolvimento de um projeto,
facilitando o desenvolvimento e fazendo que o desenvolvedor foque nas regras de
negócio.

Como muitos desenvolvedores web, saíram do desenvolvimento desktop,


uma das principais dificuldades é a criação dos layouts das páginas geralmente
feitas pelo web designer. Como o layout da página é parte fundamental do
desenvolvimento web, existe muitos frameworks para esse fim, criado
especificamente para se integrar com o JSF, facilitando e agilizando essa etapa do
desenvolvimento.
65

Pode se dizer que a interatividade é uma das características que mais


chama a atenção dos usuários na web. Devido a esta necessidade, os sites
dinâmicos devem apresentar cada vez mais componentes interativos que são
chamados de RIA(Rich Internet Applications). A tecnologia JSF estabelece um
padrão para aplicações web fundamentadas em componentes de interface que junto
com o uso de Ajax, proporcionam uma experiência cada vez mais próxima de um
software desktop. Isto é feito com componentes de interface gráfica que interagem
com os objetos de negócio de forma simples.

6.3.1.1 - Principais frameworks RIA para JSF ( JavaServer Faces)

Framework Descrição
PrimeFaces kit mais popular da atualidade, com
muitas opções, inclusive versão para
mobile.
JBoss RichFaces kit muito utilizado pela comunidade,
com muitas opções e recursos ajax
adicionais interessantes.
ICEfaces kit muito interessante, com muitas
opções que usam um tecnologia de
renderização diferencia chamada de
Direct-to-DOM (D2D).
OpenFaces kit que vem ganhando bastante
maturidade nos últimos tempos, com
muitas opções interessante,
caminhando para os tops dos mais
usadas.
Apache Tomahawk Componentes da Apache Software
Fundation.
Jenia Faces Vários componentes diferenciados.
Web Galileo Faces Vários componentes diferenciados.
GMaps4JSF Componentes da Google integrando o
GoogleMaps com o modelo de JSF.
Tabela 9 – Principais Frameworks RIA para JSF
66

Conceitualmente poderia se usar todos no mesmo projeto, embora não seja


necessário. Mas a relatos que a pratica pode não funcionar, um kit pode prejudicar
recursos de um outro kit, fazendo assim a necessidade de ser avaliado cada caso.

As principais tecnologias para desenvolvimento Web em Java como Spring,


Spring-Annotation, Spring-Webflow, Hibernate, EJB3, JPA, JBoss Seam, Acegi,
JAAS, Struts, Struts2, GWT, Portlets e etc., disponibilizam seus recursos para serem
integrados com o JavaServer Faces.

Por o JSF ser um padrão para desenvolvimento web em Java, faz com que
cada vez mais apareçam ferramentas que disponibilizam a integração com o
JavaServer Faces, fazendo assim que cada vez mais o desenvolvedor JSF esteja
amplamente amparado para buscar a melhor solução para os problemas do dia-dia.

6.3.2 - CakePHP

Não há muita informação de como integrar o CakePHP com outros


frameworks, o que se vê geralmente é exemplos da comunidade PHP, mostrando
algumas integrações com outras ferramentas.

A utilização da biblioteca JavaScript JQuery para customização de páginas é


uma das mais usadas com o CakePHP, mesmo utilizando a biblioteca do JQuery, o
desenvolvedor deve ter um conhecimento prévio de HTML, CSS e JavaScript para
customizar a aparência das suas páginas Web juntamente com o CakePHP.

Uma ferramenta muito comentada pela comunidade PHP é a integração do


CMS (Sistemas Gerenciadores de Conteúdo) Joomla com sites desenvolvidos em
PHP, há poucas informações de como integrar Joomla com o CakePHP, mas como
as duas ferramentas são desenvolvidas para trabalhar com PHP a integração é
possível, há alguns exemplos na internet demonstrando essa integração, mas
nenhum deles seguem um padrão, necessitando assim de uma certa experiência do
desenvolvedor para executar a integração.
67

Com o crescimento do Adobe Flex para geração de interfaces RIA para web,
apareceram várias formar de integrar a tecnologia Flex com PHP. Flex possui um
formato próprio de comunicação – Action Message Format (AMF) – que é um
formato binário e nativo dentro da plataforma Flash/Flex.

Existem várias implementações do AMF para PHP, assim como o PHP, o


CakePHP ainda não possui uma forma padrão e nativa do AMF. O que existe é
varias formas criadas pela comunidade para fazer essa integração.

Biblioteca Descrição
AMFPHP Utiliza-se a biblioteca dentro do
conceito de “vendors”, dessa forma a
biblioteca é inclusa no projeto, podendo
ser chamada quando necessário.
CakeAmfFPHP Puglin para CakePHP, um dos
primeiros a serem desenvolvidos, está
parado na versão 0.6 utiliza nele a
biblioteca AMFPHP.
CakeAMF Plugin que possui como
desenvolvedores parte do Core Team
do CakePHP.
CpAMF Plugin que tem como base o
CakeAmfPHP, possui atualizações
constantes.
FlexibeCake Controle que intercepta chamadas e
retorna conteúdo AMF, ele utiliza a
implementação Zend_AMF.
Tabela 10 – Bibliotecas para Interagir PHP com AMF
68

6.4 - Comunidades

6.4.1 - JSF (JavaServer Faces)

Uma das grandes forças do JSF é sua comunidade, por ser muito ativa
auxilia no aprendizado e na solução de problemas enfrentados pelos
desenvolvedores. Outro ponto positivo a respeito da JSF é o fato de ser um padrão
aberto, dessa forma, ferramentas e bibliotecas podem ser desenvolvidas por
diversas empresas ou comunidades e o desenvolvedor não fica preso às mudanças
de humor de uma empresa ou mesmo a um único projeto.

O JSF é atualmente considerado pela comunidade Java como a última


palavra em termos de desenvolvimento de aplicações Web utilizando Java, resultado
da experiência e maturidade adquiridas com o JSP/Servlet (Model1), Model2 (MVC)
e Struts.

Com uma comunidade forte e consolidada tanto no Brasil como no resto do


mundo o JSF transmite para o desenvolvedor a segurança de estar utilizando uma
tecnologia que não é apenas um modismo de época e sim um padrão de mercado
apoiado por muitas empresas e comunidades pelo mundo. Isso traz segurança às
empresas na definição de uma tecnologia a ser utilizada em seus projetos e
tranqüilidade aos estudantes para escolherem uma tecnologia que não
desaparecera do mercado rapidamente.

O que é importante é que as melhorias realizadas no JSF no passar do


tempo são feitas graças à contribuição da comunidade isso garante que as
modificações serão sempre úteis no final para o desenvolvedor, garantindo assim
uma especificação válida, confiável e útil.

A comunidade Java realiza eventos ao redor do mundo, o Brasil recebe


eventos internacionais além de ter muitos eventos realizados pela comunidade
brasileira. Como o JSF é uma especificação do Java EE seus recursos, novidades e
futuras mudanças são sempre discutidos nos eventos da comunidade Java ao redor
do mundo.
69

No Brasil e no mundo a muitos sites, fóruns, revistas e grupos de estudo


sobre JSF, os principais são:

 http://javaserverfaces.java.net/;
 http://groups.google.com/group/javasf;
 http://www.jsfcentral.com/;
 http://www.javaserverfaces.org/;
 https://javaserverfaces.dev.java.net/mailinglists.html;
 http://myfaces.apache.org/mail-lists.html;
 http://forums.java.net;
 https://javaserverfaces.dev.java.net/issues/;
 http://www.java.net/blogs/edburns/;
 http://weblogs.java.net/blog/rogerk/;
 http://blogs.sun.com/rlubke/;
 http://www.java.net/blogs/driscoll/;
 http://blogs.steeplesoft.com/;
 http://davidgearyblog.wordpress.com/;
 http://andyschwartz.wordpress.com/;
 http://mkblog.exadel.com/;
 http://www.mundoj.com.br;
 http://javafree.uol.com.br;
 http://www.oracle.com/technetwork/java/javamagazine/index.html;
 http://www.devmedia.com.br/java;
 http://soujava.org.br/

6.4.2 - CakePHP

CakePHP possui uma comunidade ativa, a comunidade tenta mostrar que é


possível desenvolver em PHP aplicações robustas rapidamente utilizando este
framework para desenvolvimento ágil para web, como se faz a mais tempo em
linguagens de programação como o Java e Ruby.
70

O CakePHP ainda não é considerado o framework para desenvolvimento


web padrão utilizando a linguagem de programação PHP, mas nos últimos 3 anos
sua utilização por desenvolvedores PHP vem crescendo muito no Brasil e no resto
do mundo. Muito disso é pela organização de sua comunidade, responsável pelo
seu desenvolvimento e melhorias realizadas nas ultimas versões. Uma das grandes
realizações da comunidade nas ultimas versões do CakePHP, é o esforço em
melhorar sua documentação e traduzi-la para vários idiomas. A comunidade vem
crescendo muita no Brasil, hoje já existe fóruns, grupos de estudos e eventos
realizados nas principais capitais do país.

Uma das grandes realizações da comunidade CakePHP foi a criação de um


canal de vídeos na Internet chamado CakePHP TV, a idéia principal da comunidade
é que desenvolvedores mais experientes disponibilizem vídeos tutorias e seus
conhecimentos com os desenvolvedores que estão iniciando no framework, tentando
assim aumentar cada vez mas a utilizaram do framework entre os desenvolvedores
PHP. As principais fontes de informações da comunidade CakePHP no Brasil e no
mundo são:

 http://tv.cakephp.org;
 http://bakery.cakephp.org;
 http://cakephp.org;
 http://groups.google.com/group/cake-php;
 http://book.cakephp.org;
 http://blog.cakephp-brasil.org;
 http://groups.google.com/group/cake-php-pt;
 http://cakebaker.42dh.com;
 https://github.com/cakephp/cakephp;
 http://www.revistaphp.com.br;
 http://forum.imasters.com.br/forum/265-cakephp-forum-oficial-do-brasil-
cakephpcombr/;
 http://www.cakephpforum.net.
71

CONCLUSÃO

Com esse trabalho pode-se dizer que não existe um molde para que um
framework MVC seja selecionando, entretanto, pode-se observar algumas das
particularidades que podem influenciar na escolha. Em termos de aplicações é
possível construir aplicações que utilizem tanto o framework JavaServer Faces
quanto o CakePHP, em ambos os casos há uma estrutura bem definida que satisfaz
o negócio das organizações.

Foram apresentadas as características principais de cada tecnologia


abordada, citando seus recursos, integrações com outras tecnologias,
documentação, curva de aprendizagem e comunidades, mostrando alguns exemplos
de códigos das principais necessidades de um desenvolvedor web.

Com base nos estudos realizados sobre os dois frameworks é possível dizer
que o JavaServer Faces possui vantagens sobre o CakePHP em termos de
desenvolvimento web.

O JSF se mostra mais maduro e estruturado, isso muito se dá por o mesmo


ser o padrão de desenvolvimento web com linguagem de programação Java. A
grande vantagem do JSF é a linguagem de programação que esta por trás do
mesmo o Java. Por ser a especificação de um framework para aplicação web
definido na padronização do Java EE, isso faz com que os desenvolvedores e
empresas tenham tranqüilidade em optar pela tecnologia que garante suporte à
mesma no futuro.

Outra vantagem importante do JSF é sua integração com outras tecnologias,


fazendo com que o desenvolvedor utilize o JSF no que ele é melhor e use recursos
de outras tecnologias para suprir as necessidades no desenvolvimento de um
projeto.

O CakePHP se mostrou ser um dos principais frameworks de


desenvolvimento web utilizando a linguagem de programação PHP. Apesar de novo
é um framework bem organizado com uma comunidade muito ativa, que se propõem
72

em torná-lo num futuro próximo o framework padrão para desenvolvimento web em


PHP. A grande desvantagem do CakePHP para o JavaServer Faces e a linguagem
de programação por trás de cada framework. O JSF por utilizar Java abre muitas
possibilidades para o desenvolvedor, enquanto o PHP ainda é limita em
determinados recursos.

Os dois frameworks fazem bem o que se propõem a fazer, ambos são


desenvolvidos e estão em constante evolução. Pode-se dizer que a utilização do
CakePHP em construção de projetos mais simples como sites, portais, lojas virtuais
é muito interessante pelo fácil aprendizado, podendo facilmente montar uma equipe
capacitada para o desenvolvimento do projeto.

Pensando em grandes projetos que estão sempre em evolução e integração


com outras tecnologias o JavaServer Faces se mostra superior, principalmente
porque esses tipos de projetos estão em constantes mudanças, e por o JSF utilizar a
linguagem de programação Java o torna uma ferramenta que pode interagir com
outras tecnologias sem muitos problemas.
73

REFERÊNCIAS

CABRAL, Cauan. CakePHP + Adobe Flex. Disponível em <


http://www.slideshare.net/cauancabral/cakephp-adobe-flex-v2>. Acesso em: 23 de
Setembro de 2011.

CAKEPHP. Componentes Principais. Disponível em <http://book.cakephp.org/pt>.


Acesso em: 29 de Maio de 2011.

CAKEPHP. Desenvolvimento com CakePHP. Disponível em


<http://book.cakephp.org/pt>. Acesso em: 23 de Julho de 2011.

CAKEPHP. Validações de Dados. Disponível em <


http://book.cakephp.org/pt#!/pt/view/1143/Validação-de-dados>. Acesso em: 29 de
Maio de 2011.

CONCEIÇÃO, Rodrigo Menezes Da. JavaServer Faces(JSF) Um Estudo


Comparativo Entre Bibliotecas de Componentes, 2008, 94p. Monografia
(Bacharel em Sistema de Informação) – Universidade Tiradentes, Aracaju, Sergipe.

FRANÇA Mendonça, Rafael. MVC - Padrão Arquitetural MVC e suas aplicações para
WEB. Disponível em <http://www.slideshare.net/rafael.ufs/padro-arquitetural-mvc-e-
suas-aplicaes-para-web>. Acesso em: 02 de Junho de 2011.

FRANZINI, Fernando. Principais Framework RIA para JSF. Disponível em <


http://fernandofranzini.wordpress.com/2011/09/14/referencia-javaserver-faces-2/>.
Acesso em: 20 de Setembro de 2011.

GEARY, David; HOSTMANN, Cay. Core JavaServer Faces - Fundamentos; trad.


Patrícia Azeredo e Fausto Magalhães. 2ª ed. Rio de Janeiro: Alta Books, 2007.
544p.
74

IBM. Validações de Dados do CakePHP. Disponível em <


http://www.ibm.com/developerworks/br/library/os-php-cake1/section5.html>. Acesso
em: 29 de Maio de 2011.

LAMIM, Jonathan. MVC - O padrão de arquitetura de software. Disponível em <


http://www.oficinadanet.com.br/artigo/1687/mvc_-
_o_padrao_de_arquitetura_de_software>. Acesso em: 02 de Junho de 2011.

LEMONCAKE. Using AclBehavior in CakePHP. Disponível em <


http://lemoncake.wordpress.com/2007/07/15/using-aclbehavior-in-cakephp-12/>.
Acesso em: 29 de Maio de 2011.

LOPES, Laura. CakePHP. In: WORKSHOP CAKEPHP - TARGETTRUST, 10, 2009,


Porto Alegre, Rio Grande do Sul. Disponível em:
<http://www.slideshare.net/lauralopes/cake-php-
2356380?src=related_normal&rel=4204625>. Acesso em: 23 de junho de 2011.

MANN, Kito D. JavaServer Faces In Action. Manning, 2004. 702p.

PALÁCIOS, Rodrigo; Nishi, Edson. JavaServer Faces – Navegação de Páginas.


Disponível em < http://xa.yimg.com/kq/groups/25266896/1828489936/name/01-JSF-
Navegacao+%5BModo+de+Compatibilidade%5D.pdf>. Acesso em: 03 de Agosto de
2011.

PONTE, Rafael. Anatomia do JSF – JavaServer Faces. Disponível em <


http://www.rponte.com.br/wp-content/uploads/2007/10/anatomia-jsf-javaserver-faces-
cct.pdf>. Acesso em 10 de Julho de 2011.

OLIVEIRA, Breno. Utilizando o CakePHP. Disponível em <


http://imasters.com.br/artigo/6076/cakephp/utilizando_o_cakephp/>. Acesso em: 14
de Julho de 2011.
75

SCRIBD. Desenvolvendo Inteligentemente com JavaServer Faces - Componentes.


Disponível em <http://pt.scribd.com/doc/55404142/11/CAPITULO-1-%E2%80%93-A-
FUNDACAO-DO-JSF-COMPONENTES-25>. Acesso em: 10 de Junho de 2011.

SCRIBD. Desenvolvimento Web com JavaServerfaces - Backing Beans. Disponível


em < http://pt.scribd.com/doc/49828432/35/Backing-beans>. Acesso em 23 de Junho
de 2011.

WIKIPEDIA. CakePHP. Disponível em < http://pt.wikipedia.org/wiki/CakePHP>.


Acesso em: 20 de Julho de 2011.

WIKIPEDIA. CGI (Common Gateway Interface). Disponível em


<http://pt.wikipedia.org/wiki/CGI>. Acesso em: 24 de Julho de 2011.

WIKIPEDIA. Framework. Disponível em <http://pt.wikipedia.org/wiki/Framework>.


Acesso em: 24 de Agosto de 2011.

WIKIPEDIA. Joomla. Disponível em <http://pt.wikipedia.org/wiki/Joomla>. Acesso


em: 26 de Setembro de 2011.

Você também pode gostar