Desenvolvimento de um site com Codeigniter

O nascimento de um site com
Codeigniter - Intro
Olá a todos,

Decidi dar início a uma série de tutoriais à medida que vou, eu mesmo, desenvolvendo
uma aplicação web recorrendo ao CI.
A aplicação consiste num site que deverá ter pelo menos, o seguinte:

.Produtos e Categorias
.Login para administração.
.Validação de Formulários
.Paginação de Resultados.

Mas deixem-me pedir, desde já, desculpas. A qualidade, apesar do meu esforço
herculiano, será baixa. Senão veja só:

. Sou novo em OOP.
. Sou novo em PHP.
. Sou novo na Programação em geral.
. MVC é absolutamente complexo aos meus olhos.
. Não sou Programador (minha formação é em Filosofia).

No entanto, decidi avançar por três motivos:
a) partilho a minha experiência no desenvolvimento com CI com outros usuários
inexperientes que, apesar dos artigos não serem de grande nível podem, contudo, ajudar.
b) fico com o registo escrito daquilo que desenvolvi para que, mais tarde, caso queira
lembrar alguma coisa, aqui estará. :)
c) estou seguro pois, como pode haver comentários, se eu disser alguma parvoíce (ou
como dizem: bobagem), haverá sempre alguém que poderá dizer: "Isso não está
correcto."

Portanto, não vejam estes artigos como uma aula mas, antes, como uma partilha de
experiência ok? :)

Esta é a introdução, esta foi também uma apresentação aí para a malta do CI Brasil.

Vamos a isto então. :-)

Próxima paragem: O nascimento de um site com Codeigniter - Estrutura e Preparação
do Site - Parte I

Codeigniter - Estrutura e Preparação do
Site - Parte I

Antes de avançar para o código, uma das primeiras coisas com que teremos de tentar
perceber, é a estrutura de directorias do site.
Nesta parte I, vamos falar dessa estrutura de directórios.

1) AS PASTAS DO ARQUIVO CodeIgniter_1.7.1.zip :
Nós fazemos o download do CI (neste caso, versão 1.7.1) e vimos logo um conjunto de
directorias que queremos colocar no nosso servidor para começar a desenvolver com CI.
Contudo, antes mesmo de colocá-las no nosso servidor, resolvi fazer o seguinte:

1.1)
Remover a pasta user_guide; - Afinal ela estará online e sempre actual. Acho que não
vale a pena fazer upload do user guide.

1.2)
Aceder à pasta system e, lá dentro, mover a pasta "application" para o mesmo nível da
nossa passa system.

Teremos então a seguinte estrutura:

/application
/system
- index.php
- license.txt

2) FAZER O UPLOAD DOS FICHEIROS:
No meu host, e calculo que em muitos outros, existe uma pasta private que não é
acessível a partir do browser, (embora o seja a partir de FTP de script e localmente) e
uma pasta public_html ou www que é pública e, como tal, acessível a partir de um
cliente.

2.1)
Decidi então aproveitar essa estrutura já existente e colocar na pasta privada o seguinte:

/private
/application
/system

2.2)
Na pasta pública, decidi colocar o seguinte:

/www
/assets (pasta contendo os nossos ficheiros .js , .css, imagens etc... )
- index.php
- license.txt
- .htaccess

2.3)
A pasta controllers e views conterão uma subpasta chamada admin, onde terei o
código dos controladores e as views, referentes à zona de administração do site. Assim:

/private
/application
/controllers
/admin
/views
/admin

3) CONVENÇÕES
Finalmente, acho que é uma boa prática ter convenções de nomenclatura. Fazendo tudo
isso sozinho, não terei responsabilidades acrescidas para mostrar o meu código a outrem
e ser coerente. Mas, a verdade é que, mesmo para nós próprios, a coerência ajuda.

Resolvi usar as seguintes convenções:
.Todos os meus Models terão o prefixo de m_ ;
.Todos os meus Controllers terão o prefixo de c_ ;
.Todos os meus Views terão o prefixo de v_ ;

.Todos os meus Templates terão o sufixo de _tpl ;

Com esta estrutura, poderemos então fazer o upload. Uma vez feito, estaremos prontos
para tratar das configurações do CI. Essas configurações, contudo, serão tratadas no
nosso próximo tutorial:

O nascimento de um site com Codeigniter - Estrutura e Preparação do Site - Parte II

Abraço,
Márcio

Site - Parte II
Este tópico é também bem simples, vamos então tratar das configurações da nossa
aplicação:

Note que algumas partes deste tópico foram já desenvolvidas num outro tutorial,
contudo, achei por bem, ainda assim, criar um tópico dedicado a isto. Notem porém que,

porque já há um tutorial bem detalhado sobre o .htaccess e a remoção do index.php e,
ainda por cima, feito por alguém bem mais capaz do que eu, resolvi colocar mais código
e menos comentário nesse tópico. Vamos a isso?

.htaccess:
O ficheiro .htaccess conterá o seguinte: (notem os comentários no .htaccess (que
começam pelo cardinal).

1. #Para não permitir o acesso ao ficheiro .htaccess vamos
colocá-lo com permissões:644. E, adicionar o seguinte:
2. <Files .htaccess>
3. order allow,deny
4. deny from all
5. </Files>
6.
7. #Nao permitir o Directory Listing:
8. Options -Indexes
9.
10. #Remove o índex.php do URL - url friendly:
11. <IfModule mod_rewrite.c>
12. RewriteEngine On
13. RewriteCond %{REQUEST_FILENAME} !-f
14. RewriteCond %{REQUEST_FILENAME} !-d
15.
16. RewriteRule ^(.+)$ index.php?$1 [L]
17.
18. #Nao permitir hotlinking:
19. RewriteCond %{HTTP_REFERER} !^$
20. RewriteCond %{HTTP_REFERER}
!^http://(www.)?mysite.com/.*$ [NC]
21. RewriteRule .(gif|jpg|js|css|png|jpeg|swf)$ -
[F,NC,L]
22. </IfModule>

application/config/config.php:

1. $config['base_url'] = "http://mysite.com/";
2. $config['index_page'] = ‘’;

em application/config/routes.php:

1. /*
2. * o nome do ficheiro controller que vai ser activo quando
se escreve:
3. * <a href="http://www.meusite.com"
title="http://www.meusite.com">http://www.meusite.com</a>
:
4. *
5. */
6. $route['default_controller'] = 'c_homepage';

em application/config/autoload.php, vamos colocar libraries e helpers do CI que
iremos usar com frequencia ao longo do site:

Coloque-as de acordo com as necessidades do seu projecto, para não estar a ocupar
recursos desnecessariamente:

1. $autoload['libraries'] =
array('database','session','email','validation','paginatio
n');
2. $autoload['helper'] =
array('url','form','text','date','security');

Não se esqueça que mudamos a localização das pastas para uma pasta private no tutorial
anterior. Ora, temos de editar o nosso index.php da seguinte forma(pelo user guide do
CI, sabemos que temos de usar um fullpath)

1. $system_folder = "/home/mysite/private/system";
2. $application_folder = "/home/mysite/private/application";

application/config/database.php
Finalmente, veja configure o ficheiro database.php. (Note a mudança no uft8)

1. $active_group = "default";
2. $active_record = TRUE;
3.
4. $db['default']['hostname'] = "localhost:/tmp/mysql.sock";
5. $db['default']['username'] = "myusername";
6. $db['default']['password'] = "mypassword";
7. $db['default']['database'] = "mydatabase";
8. $db['default']['dbdriver'] = "mysql";
9. $db['default']['dbprefix'] = "";
10. $db['default']['pconnect'] = TRUE;
11. $db['default']['db_debug'] = TRUE;
12. $db['default']['cache_on'] = FALSE;
13. $db['default']['cachedir'] = "";
14. $db['default']['char_set'] = "utf8";
15. $db['default']['dbcollat'] = "utf8_unicode_ci";
//unicode em vez de general

Este foi bem rápido e leve. Contudo, procurei ser correcto nos nomes e usar alguns
nomes em inglês para que, caso algum conceito não seja claro para si, possa recorrer a
um motor de pesquisa, e encontrar o(s) seu(s) significados. (ie. hotlinking, libraries,
helpers...).

Bem, o interessante está ainda para vir. :-)
No próximo tutorial, vamos falar da estrutura das Views. Como o tópico é bem grande,
iremos dividi-lo em episódios.
Até ao próximo tutorial: O nascimento de um site com Codeigniter - Estrutura e
Preparação do Site - Parte III - Episódio 1 de 3

ps- vou escrevendo conforme vou tendo tempo, uns tutoriais podem seguir seguidos,
outros podem levar semanas de intervalo. :( Depende do trabalho aqui deste lado ok?

Abraço,
Márcio

Se logue ou se registre para poder enviar comentários
6039 leituras

Deveria ta na documentação do codeigniter
Enviado por drfranca em qua, 11/10/2010 - 18:08.

Seu post salvou a lavoura, deveria ter algo assim no Introdução do Codeigniter.
Brigadão!


Oi márcio, antes de mais nada
Enviado por vitor.vgb em sex, 09/25/2009 - 20:55.

Oi márcio, antes de mais nada gostaria de parabeniza-lo pelos post... muito interessante,
tou ansioso pra testar. Só queria se fosse possível vc me explicasse essa parte
"application/config/routes.php:"
"
$route['default_controller'] = 'c_homepage';
"
Mais especificamente esse comando. eu deixo do jeito que tá mesmo?!
abraço

Site - Parte III - Episódio 1 de 3
Olá uma vez mais. :-)

Este é um assunto bem grande. Bem, no fundo, todos são assuntos bem grandes,
dependendo apenas da profundidade com que os estudamos. Mas neste, eu tive que
perceber bem, como funciona isto das Views. Nesta altura, ainda não percebi tudo. Mas
o suficiente para as fazer funcionar. Vamos ver.
Existem muitas maneiras de lidar com as views. Podemos estender o controller,
podemos usar um sistema de templates tipo smarty ou outro. Na Wiki do CI haverá
ainda algumas outras opções. Mas, como eu gosto de manter tudo muito simples quando
estou aprendendo, optei por seguir a sugestão dada aqui:
(http://codeigniter.com/forums/viewthread/97702/)

1) - O template:
A dificuldade deste tópico prende-se, não tanto com as próprias views e modo como nós
podemos vê-las a funcionar pois, felizmente, a gooracle está cheio de exemplos desse
tipo, a dificuldade está em como estruturar essas várias views que haveremos de ter, de
maneira eficiente. É na resposta a esta eficiência que esta questão se torna complicada,

contudo, apesar das várias formas de resolver a questão apontadas em cima, nós
optamos aqui por usar templates.

1.1)
Conceptualmente, deveremos imaginar um template como um molde, onde as várias
páginas do nosso site irão se adequar. Dito isto, deveremos analisar (olhando para o
layout das páginas que estamos a desenvolver) quais as partes que vão se manter e quais
vão mudar, de página para página.
Imaginemos que, na nossa estrutura, temos um cabeçalho sempre igual e um rodapé
sempre igual mas que, contudo, a parte central vai-se modificando de página para
página.
Detectamos então 3 partes:
Um $header; um $main e um $footer.

Vejamos o nosso template chamado geral_tpl.php :

1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
strict.dtd">
2. <html xmlns="http://www.w3.org/1999/xhtml">
3. <head>
4. <meta http-equiv="Content-Type"
content="text/html; charset=utf-8" />
5.
6. 
7. <title><?php echo $titulo;?></title>
8.
9. </head>
10.
11. <body>
12. <div id="container">
13.
14.
15. 
16. <?php $this->load-
>view('v_header'); ?>
17.
18. 
>view($main); ?>
20.
21.
22. 
>view('v_footer'); ?>
24.
25.

26. </div>
27. </body>
28. </html>

1.2) A explicação - as views v_header e v_footer:
Esta é a nossa primeira view. :-)
Em vez de chamarmos o cabeçalho e o rodapé em cada página, optamos por chamá-los
apenas no template. Assim, de cada vez que um controlador chamar uma view, ele
poderá chamar a view template que, por sua vez, chamará as views do cabeçalho e do
rodapé.

<?php $this->load->view('v_header'); ?>

<?php $this->load->view('v_footer'); ?>

O nosso cabeçalho e o nosso rodapé não poderiam ser mais simples:
Cabeçalho:

1. <div id="header">
2. <p>Eu sou um cabeçalho.</p>
3. </div>

Rodapé:

1. <div id="footer">
2. <p>Eu sou um rodapé.</p>
3. </div>

No próximo episódio da série das views, tentaremos explicar as partes dinâmicas do
nosso template. Próximo episódio:
O nascimento de um site com Codeigniter - Estrutura e Preparação do Site - Parte III -
Episódio 2 de 3

Site - Parte III - Episódio 2 de 3
Sim... o último episódio até foi pequeno mas, a razão para tal, deveu-se à necessidade de
dar um foco maior às partes dinâmicas do template, pois elas não parecem ser assim tão
fáceis de compreender. Pelo menos, não o são para mim. Vamos a isso?

1.3) A explicação - as partes dinâmicas do nosso template - geral
o nosso template não tratará apenas de chamar as views. Lembre-se, o principal do
template é conter toda a informação que poderá ser utilizada de igual modo, num
número significativo de páginas do nosso site.
Se nós temos um css que deverá ser usado em várias páginas, porque não chamá-lo
dentro da head tag do nosso template? Se nós temos um javascript que poderá ser usado
em várias páginas porque não, também, colocar as suas instruções dentro do template?

Está seguindo a lógica? Espero que sim.
E o nosso menu de navegação? Imaginando que temos um menu de navegação no topo
da nossa página. Onde deveremos colocar ele? No template? Ou na nossa view de
cabeçalho - v_header ?
Eu diria que depende de SUA organização. Livre escolha. :)

Mas, continuemos a analisar o nosso template:
De onde vem esta variável $titulo? E esta variável $main? É claro que estas serão as
variáveis responsáveis por dar dinamismo ao nosso template. Mas vamos por partes.

1.3.1) A explicação - as partes dinâmicas do nosso template - o $titulo

Primeiro o $titulo:
<title><?php echo $titulo;?></title>
A variável $titulo vem dos nossos controllers. Se nós tivermos falando do título da
página de produtos, então, o nosso controller de produto, deverá ter um array onde, a
sua key terá o nome de ‟titulo‟ e o seu valor, a seguinte string: “Os nossos produtos”.
Depois, esse array será carregado e associado ao nosso template. Feito isso, nós
poderemos aceder a elementos desse array a partir de variáveis. Eis um exemplo:
No nosso controller:
c_produtos.php

1. $data['titulo'] = "Os nossos produtos";
2. $this->load->vars($data);
3. $this->load->view('geral_tpl');

Simples hm? Ele guardou os dados da variável, colocou esses dados disponíveis para todas as
views através do método load->vars(), e finalmente, nós podemos carregar o nosso template
com a variável $titulo definida, que os valores aparecerão no nosso titulo da página.

Mas, não só de um controlador se faz o nosso site. Eu disse atrás que a variável $titulo
vem dos nossos controladores. O plural foi propositado. Cada controlador definirá a key
titulo com valores diferentes. Como aparece então um título diferente para cada página?
Como saberá ele que controlador carregar para mostrar uma determinada informação e
não outra?
A resposta: Pelo URI.

Estou em crer, e cada vez mais começo a notar, que o router é um elemento bem
poderoso de uma Framework. Se nós tivermos um URI assim:
http://www.meusite.com/c_produtos/ nós saberemos que o controlador a ser chamado
será o dos produtos. Logo, podemos ficar descansados que, a view que será chamada e
os dados que a view irá conter, serão os dados fornecidos por esse controlador.

1.3.2) A explicação - as partes dinâmicas do nosso template - o $main

Agora o $main:
<?php $this->load->view($main); ?>

Aqui nós estamos, claramente, a fazer o processo de load de uma view, dentro de outra
view. Confuso? Eu acho bem simples, quando comparado com o método de estender o
controller. Mas, vamos seguir o rasto desta variável $main. :)

Pelo que foi dito acerca da variável $titulo, já deveremos saber que esta variável $main
virá de um controlador, certo? E saberemos mais do que isso. Saberemos que esta
variável $main virá de um array no controlador, cuja key terá o nome de „main‟.
Ora, na nossa view, nós estamos colocando a variável $main em vez de um nome de
uma view, logo, que valor deverá ter a nossa key „main‟ no nosso array no controlador?
Espero que já tenha respondido mentalmente: “O valor da nossa key „main‟
corresponderá ao nome[1] de uma view”.

Por isso, e sem mais demoras:

1. $data['main'] = 'v_produto';
2.
4.

O processo é idêntico ao feito para a variável $titulo. Mas aqui, nós estamos passando
na key main, os nomes de uma view, neste caso, v_produto. Vamos espreitar esta view:

1. <div id=”produto”>
2. <p>Aqui estarão os detalhes dos produtos.</p>
3. </div>

E é isto. Simples simples.

[1] Qual nome? O nome da classe, ou o nome do ficheiro? O nome do ficheiro. Sem a
extensão. Porquê o nome do ficheiro e não da classe? Porque estamos trabalhando com
o URI e, lá, o valor é baseado nos ficheiros e não nos nomes das classes. O mesmo já
não se passará com os nomes dos métodos. O nosso URI poderá conter o nome dos
nossos métodos dentro das classes.

No próximo e último episódio, iremos completar o nosso template com duas coisas que
são muito frequentes ao longo de nossas páginas: CSS e Javascript em,
O nascimento de um site com Codeigniter - Estrutura e Preparação do Site - Parte III -
Episódio 3 de 3
Até lá. :)

4408 leituras

Parabens e uma duvida...
Enviado por vtpa em seg, 12/07/2009 - 10:14.

Bem, primeiramente parabéns pela serie de tutoriais.. realmente muito bom!

A minha duvida é exatamente sobre as views... onde ficam os códigos html?
dentro de um arquivo com o mesmo nome e com alguma extensão padrão (tipo .php ou
.html) em qual pasta?
ou no Banco de Dados, ou em algum outro lugar?

Desculpe, talvez seja uma pergunta básica, mas nao podia deixar de perguntar!

Obrigado e mais uma vez parabéns, aguardo o próximo tuto! ^^

www.viniciusalmeida.com.br


Resposta e outra dúvida
Enviado por NeiPCs em sex, 12/11/2009 - 03:23.

Sobre a organização das views eu entendi:
Extensão: .php
Local: /private/application/views

Quando ele menciona v_produto por exemplo, é uma view, logo deve ser criada na
pasta acima, com o nome v_produto.php.
Ao passo que c_produtos é um controller, e deve ser criado na pasta
/private/application/controllers com o nome c_produtos.php

A menção da pasta "private" é supondo que você está usando uma pasta remota via FTP
/ Painel de controle do seu site.

-----
Acessando o link do controller, me dá este erro:
Fatal error: Using $this when not in object context in
/home/meuusuario/private/application/controllers/c_produtos.php on line 4

Meu c_produtos.php esta assim:

1. <?php
3. $data['main'] = 'v_produto';
6. ?>

O que será que eu fiz de errado?


c_produtos - Corrigindo erro
Enviado por manives em sab, 11/06/2010 - 23:45.

Olá NeiPCs!
Também sou novo no CI, mas estudando é que e praticando é que se desenvolve o
conhecimento.
O que faltou no seu controller foi declarar o escopo dentro de uma classe c_produtos.

1. <?php
2. class c_produtos extends Controller {
3.
4. function index()
5. {
7. $data['main'] = 'v_produto'
8. $this->load->view('geral_tpl',$data);
9. }
10. }
11. ?>
12.
13. Se você não colocar, $this->load->vars($data); as
variáveis também ficam disponíveis na memória.
14.
15. Minha primeira contribuição para o fórum.
16.
17. Abraços,
18. Manoel Carvalho.

Manoel Carvalho
Desenvolvedor Web


Tente fazer de outra maneira
Enviado por siclaudio-acara em qui, 02/04/2010 - 13:42.

tente fazer desta maneira.

1. $this->load->view('geral_tpl',$data);

Desenvolvimento de um site com Codeigniter

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Desenvolvimento de um site com Codeigniter

Similar a Desenvolvimento de um site com Codeigniter (20)

Último

Último (20)

Desenvolvimento de um site com Codeigniter