Participe você também do desenvolvimento de nosso framework, envie-nos suas sugestões, dicas, reclamações, relate bugs, faça parte! Estaremos esperando sua contribuição.

Entre em contato direto conosco! framework@codepass.com.br

Forte abraço e sucesso sempre é o que deseja a equipe Codepass Framework.

Quando algum software está em uma versão de teste dizemos que esta é uma versão beta. Beta porque, de certa forma é uma versão secundária, uma versão lançada que ainda não tem caracteríscas para ser primária, finalizada. Nosso framework está em versão beta. Optamos por lançar uma versão 1.0 beta para que esta já vá se popularizando antes que hajam as implementações finais e os últimos ajustes.

Foram feitas grandes implementações para esta versão. Dentre elas está a classe Codepass_Configs que foi alterada e melhorada, agora você pode guardar vários dados dentro dela e recuperar em qualquer lugar de sua aplicação. Codepass_Session foi também uma grande mão na roda que preparamos para esta versão, com ela você verá uma grande facilidade em manipular sessões. Foi interessante também a criação da classe Codepass_Auth, criada para manipular login de usuário, que foi feita por um colaborador, Juan Biscaia, que viu o quanto poderia ser interessante desenvolver um módulo para um framework.

Enfim são muitas novidades, faça o download, experimente e ajude-nos a crescer! Deixem comments aí em baixo…

Forte abraço e sucesso!

Aprendendo a Usar Codepass Framework

Então vamos dar os primeiros passos com nosso framework, está empolgado? É melhor estar… Pelo caminho você vai notar várias e várias semelhanças entre Codepass Framework e Zend Framework. Isso é proposital e nos proporciona, amantes de Zend, uma agilidade a mais para aprender esse novo framework. O que acontece é que Zend é realmente um framework excelente, o que leva a não utilização dele em muitos casos é o fato dele ser muito pesado (cerca de 25Mb – Perfeito para grandes aplicativos), enquanto Codepass é extremamente leve.

Ressalto o fato de que SEMELHANÇA não significa CÓPIA de código, mas se não confia em minhas humildes palavras, por gentileza abra os códigos Zend e confira by yourself!

Enfim, vamos ao que interessa… Nós realmente queremos facilitar o trabalho para você e para isso criamos o que chamamos de BaseProject que nada mais é do que um aplicativo pronto e sem conteúdo. Clique Aqui para baixar um BaseProject prontinho e com a versão mais nova de Codepass Framework.

Agora, se o que voce quer mesmo é aprender e entender como funciona a estrutura do negócio continue lendo…

Entendendo o Framework

Este post é ENORME, utilize o índice!

• Estrutura (pastas e arquivos)
• htaccess
• O Arquivo index.php
• O arquivo configs/application.ini
• Controladores
• Models
• Views

Estrutura

Bem, em primeiro lugar vamos organizar nossas pastas para alocar nossos arquivos. Você verá na sequência que pode alterar essa estrutura a sua necessidade, mas aí é seu critério…

Perceba na figura que o arquivo index.php se localiza dentro da pasta public, lhe pergunto meu querido amigo, porque? É muito simples, você vai apontar seu DocumentRoot para cá, ou seja, ninguém no mundo inteiro terá acesso a qualquer outro arquivo que não estiver dentro desta pasta. Se algum espertinho usar um comando do tipo wget para baixar pastas e arquivos desprotegidos baixará apenas o que está aqui, nada que comprometa seu aplicativo…

- Ohhhh, é verdade! =O

- Já havia pensado nisso? Pois é, o Zend sim! Boas idéias devem ser mantidas meu caro!

Dentro desta pasta (public) você vai colocar todos os arquivos que são, como o próprio nome diz, públicos. Imagens, arquivos de flash, javascripts, stylesheets, enfim… Perfeito não? ^^


Uma observação interessante a se fazer é que as outras pastas de seu projeto realmente não poderão ser acessadas de forma alguma, mas com um detalhe, se você permitir em qualquer lugar de seu aplicativo o upload de arquivos PHP não há santo que proteja seu aplicativo, a menos que você tenha premeditado isso.

Fique esperto!

htaccess

public/.htaccess
--
# Esta linha permite acesso a qualquer um
allow from all

# Esta linha esta ativando o modo de sobrescrita
# de url (Url’s amigaveis, precisaremos delas)
RewriteEngine On

# Estamos definindo aqui que tudo que nao for
# arquivo deve-se sobrescrever e direcionar para
# o arquivo index.php
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
				

Bem acho que dispensa comentários não é… Qualquer coisa pesquise sobre htaccess ou rewrite mod apache no Papai Google.

O Arquivo index.php

- “Ok, ok… Eu já sei a estrutura que preciso, já sei configurar o arquivo .htaccess, mas meu aplicativo ainda nao funciona!”

É eu sei… =S Então vamos por a mão na massa…


Basicamente, o que você tem que fazer é instanciar a class Codepass_loader, setar as configurações iniciais e rodar seu aplicativo utilizando objeto run…

Rápido demais? Tudo bem, eu explico… Comece incluindo o arquivo Loader.php dentro da biblioteca Codepass e instanciando a classe Codepass_Loader no seu arquivo index.php:

public/index.php

	include_once '../library/Codepass/Loader.php';

	$application = new Codepass_Loader();
				

Agora utilize a função get_class_methods() do php para listar os métodos disponíveis na classe Codepass_Loader

public/index.php

	include_once '../library/Codepass/Loader.php';

	$application = new Codepass_Loader();

	echo '<pre>';
	var_dump(get_class_methods($application));
				

O resultado será:

array(12) {
  [0]=> string(10) "setLibrary"
  [1]=> string(10) "getLibrary"
  [2]=> string(10) "setIniFile"
  [3]=> string(10) "getIniFile"
  [4]=> string(14) "setEnvironment"
  [5]=> string(14) "getEnvironment"
  [6]=> string(12) "setDbConfigs"
  [7]=> string(12) "getDbConfigs"
  [8]=> string(11) "startLayout"
  [9]=> string(17) "setSessionConfigs"
  [10]=> string(17) "getSessionConfigs"
  [11]=> string(3) "run"
}
				

Bom, pelo menos na maioria dos casos acima dispensamos comentários neh!? Não? Então vamos dar uma breve explicação…

Para “dizer” ao aplicativo onde estão os arquivos Codepass e/ou outras bibliotecas de classes utilize setLibrary(‘string’), para capturar devolta essa string utilize getLibrary(). Lembre-se que o padrão é ‘../library/’, portanto se você não alterar a estrutura do exemplo não precisará mexer aqui.

Utilize setIniFile(‘string’) e getIniFile() para setar e capturar o arquivo de configurações principais. O padrão é ‘../configs/application.ini’, portanto se você não alterar a estrutura do exemplo não precisará mexer aqui.

setEnvironment(‘string’) e getEnvironment() para setar e recuperar o ambiente de desenvolvimento. Por padrão utilizamos a string ‘production’. Entenderemos melhor esse método quando formos configurar o arquivo application.ini

startLayout(‘string’) é um objeto importantíssimo! É através dele que definimos ao aplicativo qual será o arquivo utilizado para layout geral do sistema… Quando este objeto não é setado o sistema não utiliza nenhum layout padrão. Setando ou não um layout padrão você pode alterá-lo na mão dentro de cada controlador, na ação ou no método init()

Vejamos então o objeto setSessionConfigs(array) – Todos os parâmetros do array são opcionais…

public/index.php

$application->setSessionConfigs(
	array(
		// SEGUNDOS de duração das sessões do sistema
		'session_timelife' => 20,

		// Local onde salvar os arquivos de sessão
		'session_save_path' => '../arquivos/sessions/',

		// SEGUNDOS limite para login do usuário expirar
		'auth_expire' => 5
	)
);
				

Caraca! Ta quase pronto, falta apenas explicar como setar as configurações de banco de dados e o objeto run()… =D

Muito bem, Codepass Framework trabalha com PHP PDO, ou seja, está preparado para interagir com qualquer tipo de base de dados sem problema nenhum

=O

Para configurar o método setDbConfigs(array $params, $driver = ‘PDO_MYSQL’) precisamos passar o array com as configurações (host, dbname, username, password, port) e o tipo de adaptador que queremos usar (PDO_MYSQL, PDO_DBLIB, PDO_FIREBIRD, PDO_IBM, PDO_INFORMIX, PDO_OCI, PDO_ODBC, PDO_PGSQL, PDO_SQLITE ou PDO_4D), por padrão PDO_MYSQL.

A seguir o código NÃO RECOMENDADO das configurações de banco de dados padrão do sistema.

public/index.php

$application->setDbConfigs(
	array(
		'host' =>	'localhost',
		'dbname' =>	'meusite',
		'username' =>	'root',
		'password' =>	'',
		'port' => 3306
	),
	'PDO_MYSQL'
);
				

Porquê esse código não é recomendado?

Em primeiro lugar pq ele vai ficar na pasta public… Senha numa pasta pública? Acho que não neh!?

=/

Em segundo lugar porque você provavelmente vai usar seu aplicativo em outro ambiente (produção, homologação). Assim nesse caso teria que ficar alterando na mão a configuração do banco de dados…

Segue agora então o código RECOMENDADO!

configs/database.ini

[development]
driver = PDO_MYSQL
params.host = localhost
params.username = root
params.password =
params.dbname = mydbname
params.port = 3306

[production]
driver = PDO_MYSQL
params.host = localhost
params.username = root
params.password = mypwd
params.dbname = mydbname
params.port = 3306
				

Note que temos uma chave “development” e uma chave “production”. Isso é o ambiente de execução que você setou acima, lembra? $application->setEnvironment(‘production’) ou $application->setEnvironment(‘development’)…

public/index.php

// Primeiro vamos recuperar a instância da classe Codepass_Configs
// Esta classe tem o poder de armazenar conteudos de arquivos INI
// para serem recuperados em qualquer lugar do aplicativo
$configs = Codepass_Configs::getInstance();

// Adicionamos a ela uma configuração. Para isso basta darmos um nome
// a esta configuração e passarmos o caminho do arquivo onde
// se encontram
$configs->addConfig(
	array('DB' => '../configs/database.ini')
);

// Recuperamos as configurações de banco de dados de acordo com o
// ambiente de desenvolvimento
$db = $configs->getConfigs(
	array('DB', $configs->getEnvironment())
);

// Seta configurações recuperadas no objeto setDbConfigs()
$application->setDbConfigs($db['params'], $db['driver']);
				

Lindo!! Agora é so rodarmos nosso aplicativo utilizando o método run! =D

É isso aí, agradecimentos a equipe técnica… O que? Não funcionou? Mas… Como?… Ahhh é claro, não configuramos os aquivos INI ainda, nem sabemos como fazer isso… ”/ Ok, ok, suspende o lanche…

O arquivo configs/application.ini

Ali em cima você pode notar que utilizamos um arquivo INI para setar as configurações de banco de dados de forma rápida e simples não é mesmo? Pois bem, vamos agora configurar o arquivo application.ini que é o arquivo que comanda a parada…

Nele, vamos setar as configurações de pastas de controladores, models, views e layouts além das configurações de erros do sistema de acordo com o ambiente de execução do aplicativo.

configs/application.ini
--
[paths]
application.controllers = "../application/controllers/"
application.models = "../application/models/"
application.views = "../application/views/scripts/"
layout.path = "../application/views/layouts/"

[development]
errors.reporting = E_ALL
errors.display = 1

[production]
errors.reporting = 0
errors.display = 0
				

O índice “paths” dispensa comentários não é? São os caminhos para as camadas MVC e arquivos de layout.

A parte legal mesmo está um pouquinho mais para baixo, nos índices “development” e “production”. Esses meu caro, são os ambientes de execução de nosso aplicativo, que são setados através do objeto Codepass_Loader::setEnvironment(‘string’) no arquivo public/index.php. Você pode criar quantos índices (ambientes) quiser, por exemplo, você pode ter um índice “homologacao” que será um ambiente o mais parecido possível com “production”, geralmente usado para teste ou para mostrar a um cliente etc…

Quando você estiver desenvolvendo seu aplicativo localmente deixará o environment setado como ‘development’, assim os erros do sistema, como setado no arquivo configs/application.ini, aparecerão na tela quando ocorrerem, mas quando for subir seu aplicativo, você setará como ‘production’ e os erros ficarão invisíveis para o usuário.

Além do mais, como utilizamos um arquivo INI específico para banco de dados e também com índices de ambiente de desenvolvimento, Não precisaremos mudar online cada configuração do database, pois através do índice escolhido o próprio aplicativo usará o banco correto.

Prático não? =D

Ok, vamos agora rodar nosso aplicativo para ver se funciona!

Codepass_Exception' with message 'Wrong class name on file
../application/controllers/ErrorController.php, use ErrorController
				

Ops, não configuramos os controladores ainda… =/

Controladores

O primeiro controlador que precisamos configurar é o ErrorController, pois é ele quem gerenciará os erros do sistema como por exemplo um erro de página não encontrada 404. Esse controlador é padrão do sistema, ou seja, obrigatório! O sistema não funcionará sem ele! Alguém tem que fazer o trabalho sujo não é mesmo? =/

Antes de começarmos a escrever o código vamos entender o que são controladores… Controladores é uma camada MVC que faz a comunicação entre o banco de dados e os dados que serão exibidos na tela, mais ou menos da seguinte forma…

O usuário envia um comando através da view para o controlador que vai tratar a “pergunta” e “pedir” do banco de dados a resposta através da model. Retorna para o controlador que trata esse resultado e então repassa para a view que transforma o dado de linguagem de máquina para algo legível para um ser humano. Simples!

Segue o básico para qualquer controlador

application/controllers/IndexController.php

class IndexController extends Codepass_Controller_Settings
{
	/**
	 *	Este método é executado antes de qualquer ação
	 */
	public function init() {

	}

	/**
	 *	Esta ação é executada ao digitar
	 *	http://seusite.com.br/index/index
	 * 	ou nada porque o padrão é index tanto
	 *	para controladores quanto para ações
	 */
	public function indexAction() {

	}

	/**
	 *	Esta ação é executada ao digitar
	 *	http://seusite.com.br/index/test
	 */
	public function testAction() {

	}
}
				

Quem está acostumado com Zend só precisa se ligar que a classe a quem o controlador extende é Codepass_Controller_Settings

Baixando o BaseProject você vai notar que já disponibilizamos um layout pronto para os erros do sistema.

Models

Não vamos falar sobre elas, afinal para começar não precisamos usar models… =D

As models são para fazer relacionamento com banco de dados, mas para mostrar o framework funcinando não precisamos de banco de dados… ^^

Views

Views… Ta aí um assunto bacana, simples e rápido…

As views são praticamente o html do aplicativo! Ou seja, depois que você tratar os dados no controlador esses têm que ter uma saída para o usuário que é o html. Tudo o que você através do objeto $this->view. Vou explicar de uma forma visual.

application/controllers/IndexController.php

class IndexController extends Codepass_Controller_Settings
{
	public function init() {}

	public function indexAction() {
		$data = array(
			'value' => 'Dado que quero passar para a view'
		);

		$this->view->data = $data;
	}
}
				

Fazendo isso, é só você recuperar na respectiva view (index/index.php)

application/views/scripts/index/index.php

<div>
	<?php echo $this->data['value']; ?>
</div>
				

That’s all folks!

É isso aí pessoal, agora já colocamos o framework para funcionar, usem e abusem, é muito importante para nós, do desenvolvimento, que você nos ajude reportando os bugs… Sácoméné!

Abraço a todos e não se esqueçam! Qualquer coisa é só mandar e-mail para marco@codepass.com.br… Flw! Vlw!