php /home//composer.phar
sempre que for usá-lo. Para isso, acessando como //root// (usando o comando ''sudo su''), digite:
mv composer.phar /usr/local/bin/composer
Já no Windows, ao invés de ter que digitar algo como:
C:\ProgramData\ComposerSetup\bin\composer
apenas vá em Painel de Controle → Sistema → Configurações Avançadas de Sistema → Variáveis de Ambiente e se a pasta'' C:\ProgramData\ComposerSetup\bin'' não estiver na variável ''PATH'', adicione-a. Saia dando OK e reinicie o terminal para pegar o caminho atualizado.
Agora é possível usar o Composer usando o comando ''composer'' de qualquer lugar.
Se o Composer reclamar que ele está antigo e pedir para se atualizar, apenas use o comando:
composer self-update
===== Laravel Homestead / Máquina Virtual =====
Framework Laravel tem alguns requisitos de sistema, esses requisitos são satisfeitos pela máquina virtual [[infotic:laravel:homestead|Laravel Homestead]], que pode ser usada para como um ambiente local de desenvolvimento.
===== IDEs =====
==== NetBeans ====
[[infotic:laravel:netbeans|Instalação e Configuração do Projeto no NetBeans]]
[[infotic:laravel:netbeansImplantando|Rodando o Projeto no NetBeans]]
===== Usando o Laravel ====
==== Instalando o Laravel e Criando um Novo Projeto ====
Para instalar o Laravel, faça:
composer global require "laravel/installer"
Certifique-se de que a pasta ''../Composer/vendor/bin'' esteja no //path// de seu sistema.
Se estiver no Windows, vá em Painel de Controle → Sistema → Configurações Avançadas de Sistema → Variáveis de Ambiente e a pasta não estiver na variável ''PATH'', adicione-a. Ela deve estar em uma pasta similar a ''C:\Users\
export PATH=/home//.composer/vendor/bin:$PATH
Para se criar um novo projeto usando Laravel, execute na pasta onde deseja colocar o projeto:
laravel new
Caso não queira instalar o Laravel globalmente ou tenha algum problema em sua instalação, principalmente no Windows, crie um novo projeto diretamente usando o composer:
composer create-project laravel/laravel
Se tiver faltando alguma extensão do PHP, no Windows é só descomentar o uso da DDL referente à extensão desejada no Windows e reiniciar o terminal. Já no Ubuntu é necessário instalar a extensão necessária com o comando:
sudo apt-get install
Antes de tentar criar o projeto novamente, apague a pasta do projeto.
==== Criando e Configurando um Banco de Dados ====
Depois de fazer o projeto lógico de seu banco, crie apenas a base de dados (sem as tabelas) localmente no gerenciador de banco de dados (SGBD) escolhido. Depois, no ''.env'', coloque as configurações de seu banco, preenchendo ''DB_HOST'', ''DB_CONNECTION'', ''DB_DATABASE'', ''DB_USERNAME'' e ''DB_PASSWORD''. Em ''config/database.php'', caso a configuração do SGBD escolhido não esteja presente, adicione-a pelo Composer, lembrando-se de que tem que adicionar o //Service Provider// em ''config/app.php''. Lembre-se de que precisa tanto ter o SGBD quanto seu driver para PHP instalados. Dependendo do SGBD, pode ser necessário adicionar alguma variável de ambiente ao ''.env''.
Em geral, não será necessário instalar a configuração de um SGBD adicional, já que o Laravel vem com PostgreSQL, MySQL, SQLite e SQLServer. O acesso ao SQLServer é que é mais complicado, pois é preciso instalar no PHP umas bibliotecas adicionais. Com as devidas bibliotecas instaladas, o acesso ao SQLServer poderá ser feito de maneira transparente pelo Laravel, da mesma forma que se acessa os outros bancos. Basicamente, é necessário ter o ''pdo_dblib'' com o '' freetds'' habilitado. Isso em Ubuntu e CentOS. Para outros SOs, pode ser que sejam necessárias mais ou menos bibliotecas adicionais.
=== Migrations ===
Agora é hora de criar as tabelas propriamente ditas. Se estiver apenas em ambiente de desenvolvimento ainda, sem dados em produção, crie uma //migration// para cada tabela. Uma //migration// é um //script// para o banco de dados que deve ser rodado sempre que for alterado. Ele facilita o desenvolvimento em grupo e a implantação da aplicação, uma vez que é só rodar o //script//. Em desenvolvimento, se precisar alterar uma tabela, apague e recrie a base no SGBD, altere a //migration// dela e mande rodar os //scripts// que elas serão criadas novamente. Já se estiver em produção com dados que não possam ser perdidos, é preciso criar uma //migration// de alteração e executá-la para não perder dados.
Para criar uma //migration// de criação de tabela, execute o seguinte comando no diretório da aplicação:
php artisan make:migration create__table --create=""
Crie primeiramente as //migrations// para as tabelas sem chave estrangeira e depois adicione as que referenciam as já criadas. Senão, ao rodar os //scripts// (que são executados todos juntos), vai dar erro dizendo que a tabela referenciada não existe, já que os //scripts// das //migrations// são executados na ordem em que foram criados.
Agora deve-se editar o método ''up()'' da //migration//, que cria vai criar tabela ao ser executado, colocando cada coluna da tabela, suas restrições, indicar as chaves estrangeiras, etc.
Em geral a coluna ''id'' que já vem com a //migration// na primeira linha da criação da tabela será a chave primária. Caso outra coluna seja a chave primária e não seja necessário o ''id'', é só removê-la e adicionar as colunas que serão a chave primária fazendo algo como:
$table->primary([
Se a chave for de apenas uma coluna, não é preciso passar um vetor de uma unidade; apenas passe o nome da coluna como parâmetro. Lembre-se de declarar a coluna, como mostrado abaixo, antes de colocá-la em uma chave ou índice.
Para declarar cada coluna, faça algo como:
$table→('', ...)->();
Os tipos da coluna justamente com os parâmetros extras, que em geral são limites de tamanho, podem ser vistos em https://laravel.com/docs/5.2/migrations#creating-columns
Após declarar a coluna, é possível declarar um ou mais modificadores para ela. Basta chamar um método ou mais métodos um após o outro com os modificadores necessários. Os modificadores são:
* ''unique()'' para dizer que os valores da coluna não podem ser repetidos;
* ''nullable()'' para dizer que a coluna aceita valores nulos (//null//);
* ''unsigned()'' para dizer que a coluna do tipo numérica não pode ser negativa, e
* ''default()'' para dar um valor '''' padrão (//default//) à coluna.
Para criar um índice, adicione à //migration// algo como:
$table→index([
Onde o nome do índice é opcional e as colunas passadas no primeiro campo são as colunas que formam o índice. Se o índice for de apenas uma coluna, não é preciso passar um vetor de uma unidade; apenas passe o nome da coluna no primeiro parâmetro. Alternativamente, ao criar a coluna, adicione o modificador ''index()'' ao seu final.
Para criar uma chave estrangeira referenciando outra tabela, faça algo como:
$table->foreign('id_')->references('id')->on('');
supondo que a chave primária de '''' seja ''id'', que é o caso mais comum.
Caso na declaração da chave estrangeira precise dizer o que fazer com a linha em caso de remoção ou alteração, após o método ''on()'', chame o ''onDelete('')'' ou ''onUpdate('')'', respectivamente.
Em alguns sistemas há tabelas que precisam ter dados desde quando o sistema é posto em produção. Neste caso, as //migrations// devem ter inserções no método ''up()'' após a criação da tabela. Exemplos são credenciais de administrador padrão para o acesso inicial a um sistema ou tabelas de tipo. Para fazer isso, use um código similar ao abaixo:
DB::table('')->insert(
array(
'' => '',
...
'' => ''
)
;
Para executar as //migrations//, execute o seguinte comando:
php artisan migrate
Se o comando for executado com sucesso, suas tabelas serão criadas na base de dados, com algumas tabelas adicionais das //migrations// que veem com o Laravel e com a tabela ''migrations''.
=== Models ===
Quem construiu esse doc, rever essa parte pfvr, considerando o comentário:
"De acordo com a documentação (https://laravel.com/docs/8.x/eloquent#local-scopes), o melhor seria ter scope method para esses casos."
Após criar e executar as //migrations//, é hora de criar uma classe para cada tabela, que é chamada de modelo (//model//), que ficarão na pasta ''app''. Cada modelo estende a classe ''Model'' e o nome deve ser em //camel case//, com o nome da classe começando com letra maiúscula. Então, se o nome da tabela for ''esqueci_senha'', o nome do modelo será ''EsqueciSenha''.
Um modelo pode ser criado com um comando com o seguinte formato:
php artisan make:model
Se usar a convenção do Laravel de nome de tabela, onde o nome de tabela é no plural com relação ao modelo representado (ex: tabela ''users'' e classe ''User''), não é necessário atribuir valor ao campo ''$table'' do modelo. Porém, essa não é a convenção que usamos quando aprendemos banco de dados. Se uma tabela representar alunos, ela se chamará ''aluno'' e não ''alunos''. Portanto, o seu modelo deve ter o seguinte campo:
protected $table = '';
O mesmo deve ser feito para a chave primária caso ela não seja a padrão, ou seja, ''id'':
protected $primaryKey = '';
Todo campo a ser preenchido que vier de um formulário, que não for automaticamente gerado, como o ''id'', que é auto-incremental, deve estar no vetor ''$fillable'':
protected $fillable = ['', … , ''];
Um campo auto-incremental de outra tabela, que é uma chave estrangeira, não deve estar presente no vetor acima, mas deve ser passado à tabela relacionada manualmente através de atribuição.
Caso haja um ou mais campos que devam ser protegidos, como senhas e //tokens// para relembrar senha, eles devem estar no vetor ''$hidden''. Obviamente, devem estar em ''$fillable'' também.
protected $hidden = ['', … , ''];
Por fim, o modelo deve incluir métodos para retornar os objetos dos modelos relacionados via chave estrangeira. Se o relacionamento for 1-1 ou 1-n, o modelo da tabela que contém a chave estrangeira deve conter um método como abaixo, supondo que a tabela ''tabela_1'' tenha uma chave estrangeira para ''tabela_2'':
public function tabela2()
{
return $this->belongsTo('App\Tabela2');
}
Já o modelo da tabela que é referenciada deve conter um método como se o relacionamento for 1-1:
public function tabela1()
{
return $this->hasOne('App\Tabela1');
}
Se o relacionamento for 1-n, o modelo da tabela que é referenciada deve conter um método como:
public function tabela1s()
{
return $this->hasMany('App\Tabela1');
}
Não é preciso se preocupar com o caso de relacionamentos n-m, já que são resolvidos com tabela de junção, formando dois relacionamentos 1-n.
Um exemplo de modelo genérico juntando todas as informações acima fica da seguinte forma, considerando que ''tabela_2'' tem chave estrangeira para ''tabela_1'' em um relacionamento 1-1:
hasOne('App\Tabela2');
}
}
Nos modelos também deve-se colocar métodos que vão consultar/alterar/inserir dados no banco. Esses métodos devem ser estáticos e, quando forem consultas, retornar os dados desejados baseados em filtros que serão passados em consultas ao banco. Não se deve acessar o banco diretamente do //controller// e sim chamar esses métodos dos modelos. Assim, se o modo como a alteração no banco é feita precisar ser modificado, mas com a mesma semântica, o código não precisará ser alterado em todos os pontos que a consulta for chamada. Em Laravel, é possível acessar e alterar os dados das tabelas com métodos que consultam e/ou alteram a tabela sem passar o comando SQL inteiro e usando estaticamente a classe do modelo, o chamado Eloquent, evitando o problema de segurança chamado SQL //injection// e simplificando a sintaxe. Por exemplo, em um modelo ''ModelName'', pode-se ter o seguinte método para buscar a primeira linha do banco de dados filtrando pelo campo ''field_name'':
public static function getByField($field_value)
{
return ModelName::where('field_name', $field_value)->first();
}
Outras maneiras de se acessar/alterar o banco em um modelo usando o Eloquent podem ser vistas em https://laravel.com/docs/5.2/eloquent. Algo interessante é que o método ''save()'' pode ser usado tanto para criar como para alterar dados do banco, simplificando a programação.
Algo interessante é que os métodos que retornam dados do banco, se não tratados e mandados diretos para o navegador, mostrarão um JSON. Isso torna o Laravel muito útil para a implementação de web services.
==== Instalando Novos Componentes ====
Muitas vezes será necessário instalar uma biblioteca nova para a aplicação. Para isso, usa-se o Composer. Para instalar um novo pacote para a aplicação, use o comando:
composer require
Pode-se também editar diretamente o arquivo ''composer.json'' do seu projeto e colocar o pacote que deseja em ''"require":'' e depois rodar o comando ''composer update''. Em https://packagist.org/ é possível ver os pacotes disponíveis.
Alguns pacotes úteis: ''laravelcollective/html'' (formulários HTML) ''xavrsl/cas'' (autenticação) e ''overtrue/laravel-lang'' (idiomas). Para editá-los diretamente no ''composer.json'', é preciso colocar diretamente a versão, ficando algo como:
"require": {
"php": ">=5.5.9",
"laravel/framework": "5.2.*",
"laravelcollective/html": "5.2",
"overtrue/laravel-lang": "~3.0",
"xavrsl/cas": "1.2.*"
},
Ao instalar um componente, pode ser necessário criar um ou mais //aliases// para acessá-lo em ''config/app.php'' no vetor ''aliases''. Assim, ao importar uma classe, o comando ''use'' ficará mais simples, pois não será necessário usar o caminho todo da mesma. Adicionalmente, todo pacote deve ser adicionado ao vetor ''providers'' (//Service Providers//) para poder ser usado.
Para os pacotes citados acima, deve-se trocar em ''providers'': ''Illuminate\Translation\TranslationServiceProvider::class'' por ''Overtrue\LaravelLang\TranslationServiceProvider::class''
e adicionar
Collective\Html\HtmlServiceProvider::class,
Xavrsl\Cas\CasServiceProvider::class
Já em ''aliases'', deve-se colocar:
'Form' => Collective\Html\FormFacade::class,
'Html' => Collective\Html\HtmlFacade::class,
'Cas' => Xavrsl\Cas\Facades\Cas::class,
Para trocar o idioma, altere em ''config/app.php'' o ''locale'' para ''pt-BR''. Finalmente, para copiar o idioma desejado de ''vendor'' para ''resources/lang/'', faça o comando
php artisan lang:publish pt-BR
Note-se que este comando não funciona automaticamente no Windows porque ele precisa do comando ''cp''. Pode-se copiar os arquivos na mão simplesmente baixando os arquivos de ''https://github.com/caouecs/Laravel-lang/tree/master/src/pt-BR'' e copiando-os para a nova pasta ''resources/lang/pt-BR''. Alternativamente, pode-se instalar o pacote Cygwin de http://cygwin.com/ para ter no //prompt// de comando os comandos de Linux.
Em https://packagist.org há vários pacotes úteis para muitas funcionalidades, para que sua aplicação não precise "reinventar a roda". Em geral, para cada pacote, há instruções de como usá-lo, seja com o Laravel ou apenas com PHP.
==== Views ====
Uma //view// é uma tela HTML que vai receber parâmetros em PHP, usando de preferência as facilidades do Laravel, passados pelo //controller//, o que será visto posteriormente, para a exibição de dados. As //views// ficam na pasta ''resources/views''. Elas devem ser organizadas em pastas de acordo com as funcionalidades do seu sistema. Por exemplo, um sistema onde haja telas diferentes de acesso para aluno, professor e administrador, pode ter pastas com esses nomes com //views// para cada tipo de usuário. Uma maneira de organizar essas pastas é ter uma pasta por //controller//. Por padrão, existe a pasta ''errors'' para //views// que exibirão erros. Se o sistema for mandar e-mails com HTML, é interessante haver uma pasta tal como ''emails'' para ter //views// com o HTML que será usado nos e-mails.
Uma //view// tem que ter a extensão ''.blade.php''. Contudo, na hora de se referir a ela no //controller//, o formato a ser usado é
.. … ..
Então, se por exemplo uma pasta ''aluno'' contiver uma pasta chamada ''dados'' e dentro dela houver um arquivo de //view// chamado ''cadastro.blade.php'' (caminho r''esources/views/aluno/dados/cadastro.blade.php''), a //view// será acessada como ''aluno.dados.cadastro''.
=== Templates ===
Em geral um sistema terá telas que terão código HTML em comum. Como é uma péssima prática repetir o código, usa-se //templates// para torná-lo mais fácil de entender. Laravel te ajuda a fazer um //template// de forma muito fácil.
Um //template// é uma página web do PHP padrão que fica no diretório ''views'', mas com “pedaços” que serão preenchidos nas páginas que seguirem esse //template//. Portanto, os //templates// também são //views//, porém com sessões incompletas que precisam ser preenchidas pelas //views// propriamente ditas. Um //template// tem sessões que são declaradas em uma linha com formato ''@yield('')'' e as //views// que a usarem precisam ter o seguinte formato:
@extends('')
...
@section('')
...
@stop
...
@section('')
…
@stop
Um //template// pode estender outro //template// e esse processo pode ser feito em cascata para aproveitar a estrutura já existente e evitar a repetição desnecessária de código. Nesse caso, o nome das sessões devem ser diferentes para não dar conflito.
=== Views Parciais ===
Às vezes uma parte de uma //view// será repetida em várias //views//. Ao invés de se criar um //template//, cria-se uma //view// parcial, que será incluída nas //views// que precisarem desse pedaço de código usando:
@include('')
Obviamente, uma //view// parcial não faz sentido existir sozinha. Esse problema pode ser resolvido com //templates//, porém quando se tratar de trechos de códigos isolados que serão repetidos, faz mais sentido usar //views// parciais.
=== Facilidades ===
Uma facilidade que existe no Laravel é o fato de não ser necessário usar muito código PHP diretamente nas //views//. Ao invés de usar comandos de controle em PHP, é possível usar comandos começados com ''@'' para fazer a mesma coisa. Um ''if-then-else'', por exemplo, usa os comandos ''@if'', ''@else'' e ''@endif''. Repare que todos os comandos que existem precisam de um comando para finalizá-lo. Já as variáveis em PHP que aparecem em uma //view// são passadas como parâmetro em um vetor e são acessadas começando por ''$''. Por exemplo, se ao chamar uma //view// de um //controller// se passar como parâmetro um vetor ''dados'' com a chave mensagem (''$dados[‘mensagem] = ‘erro’;''), a mensagem deve ser acessada na //view// usando ''$mensagem''.
Se usar o altamente aconselhável pacote de formulários ''collective'', é possível simplificar a construção de formulários. Cada campo do formulário será criado usando ''Form::'' juntamente com o que se deseja cololocar no HTML da //view//. Os campos devem estar entre ''{{ }}'' (para dados escapados, mais seguro, o que deve ser usado quase sempre) ou ''{!! ||}'' (para dados não escapados). Para saber o que tem disponível e exemplos, acesse https://laravelcollective.com/docs/5.2/html.
Se estiver usando o grupo de //middleware// ''web'' nas rotas que dão para as //view//s que usam o //template// base de todo o sistema (algo altamente recomendável), é possível fazer um tratamento dos erros de entrada de dados de maneira centralizada. Fazendo-se código similar ao mostrado abaixo no //template// base, consegue-se tratar erros genéricos, erros de formulário (entrada) e sucessos de forma centralizada. Note-se o uso de classes do //bootstrap//.
@if (isset($erro))
ERRO
{!! $erro !!}
@endif
@if (isset($sucesso))
{{ $sucesso }}
@endif
@if ($errors->any())
ERRO
@foreach ($errors->all() as $error)
{{ $error }}
@endforeach
@endif
=== Estilos ===
Toda página HTML tem estilos para formatá-la de acordo com o desejado. Para isso, tem-se CSS, JavaScript, fontes e imagens. Todos os arquivos referentes a estilos devem ficar na pasta ''public''.
Em geral, coloca-se os arquivos CSS na subpasta ''css'', os arquivos ''JavaScript'' na subpasta ''js'', os arquivos de fontes na subpasta ''fonts'' e os arquivos de imagens na subpasta ''img''.
Para deixar os arquivos de estilos independentes do endereço raiz da aplicação, eles devem ser importados usando a função ''asset()'' de maneira escapada na hora de referenciar o caminho do arquivo a ser importado.
Lembre-se de que //scripts// devem ser preferencialmente carregados ao final das páginas, pois se um //script// der erro, a página em si não deixará de ser carregada.
==== Rotas ====
As rotas são os endereços relativos pelos quais é possível acessar as páginas da aplicação web. Se o endereço raiz for o padrão, http://localhost:8000/public/, a rota que aponta para a raiz é ''/''. Num projeto recém criado, vem apenas uma rota que redireciona para a //view// de boas vindas. Esse exemplo redireciona diretamente para uma //view//, uma tela HTML por ser uma tela sem funcionalidades. Porém, se a tela tiver alguma interação com o usuário, coloca-se o nome da rota juntamente com o método de um //controller// a ser chamado, que por sua vez vai carregar, possivelmente passando dados, uma //view//. Para depuração, pode-se retornar também uma //string//.
É muito útil, como dito anteriormente, usar um //middleware//, seja para fazer autenticação, seja para colocar as mensagens de erro de forma padrão, tal como acontece ao usar o grupo de //middleware// ''web''. Portanto, usa-se esse tipo de código para declarar que um grupo de rotas usa um determinado //middleware// ou grupo de //middleware// em ''app\Http\routes.php'':
Route::group(['middleware' => ['']], function ()
{
...
});
Se um grupo de rotas usar mais de um //middleware// ou grupo de //middleware//, faz-se:
Route::group(['middleware' => ['', ..., '']], function ()
{
...
});
Além do ''web'', um muito usado é o ''cas'' (que precisa ser criado) para fazer autenticação central. Neste caso, apenas as rotas do sistema que precisam de autenticação precisam usar esse grupo de //middleware//.
Já as rotas propriamente ditas ficam no seguinte formato, usando-se um método de um //controller//:
Route::get('', '@');
ou
Route::post('', '@');
Uma rota com ''Route::get()'' é uma rota que apresentará uma tela. O '''' aparecerá depois do endereço da página raiz. Então, se digitar ''http://localhost:8000/public/'', o método '''' do //controller// ''nome_controller'' será invocado. Se essa rota precisar de autenticação, por causa do //middleware//, por exemplo, será direcionado a uma página para se autenticar e depois será redirecionado para a rota pedida.
Já uma rota com ''Route::post()'' é resultante da submissão de um formulário. Ela não pode ser acessada diretamente. O nome da rota vai ser a mesma usada no correspondente ''Route::get()'' que abrirá a página, mas chamará um outro método que será responsável pelo processamento de dados enviados pelo usuário.
Rotas podem receber parâmetros, que serão passados na barra de endereço após o nome da rota. Para isso, após o nome da rota em ''Route::get()'', passar ''/{}''. Pode-se passar mais de um parâmetro, um após o outro, separados por ''/''. Se algum parâmetro for opcional, faz-se: ''/{}''. Se uma rota tiver o mesmo nome de uma rota com parâmetro, a sem parâmetro deve ficar acima da com parâmetro em ''app\Http\routes.php''. Senão, ao tentar acessar a rota sem parâmetro, o Laravel vai buscar a primeira opção e achar que está tentando acessar uma rota com parâmetro sem o parâmetro e vai dar erro.
Ao escolher o nome de um rota, evite usar //underline// e sim use o hífen, para facilitar a digitação da rota pelo usuário do sistema, que não precisará ficar usando combinação de teclas, o que acelerará a digitação da mesma.
==== Controllers ====
O //controller// é onde se coloca a lógica do sistema. É ele quem carrega e passa os dados para as //views// e manda os modelos fazerem alterações no banco.
Os //controller//s ficam na pasta ''app\Http\Controllers'', e podem ser criados através do comando:
php artisan make:controller
Lembre-se de que o nome do //controller// deve ficar em //camel case//.
O //controller// deve ter como métodos públicos todos os métodos que aparecem como funcionalidade das rotas. Adicionalmente, pode-se ter métodos privados adicionais auxiliares.
As métodos públicos para as rotas que recebem parâmetros podem ter como parâmetros os passados para a rota. Se o parâmetro passado for uma chave primária de uma tabela e o parâmetro for declarado como tendo o tipo de seu respectivo modelo, o Laravel já pega o objeto da tabela representado por aquele modelo automaticamente. Para isso funcionar, o nome do parâmetro da rota tem que ser idêntico ao nome do parâmetro do método, obviamente sem o ''$'' característico de variáveis em PHP.
Já os métodos públicos para as rotas do tipo POST devem ter como parâmetro um Request, que será explicado a seguir, para fazer a validação de dados submetidos por um formulário. Se for desejado voltar para a rota GET que originou o POST na hora da submissão do formulário, o método que trata a rota POST deve terminar com
return back();
O número de //controller//s em uma aplicação varia de acordo com a estrutura da aplicação. Pode-se ter um //controller// por um grupo de //views// que pertencem a um mesmo grupo de funcionalidades. Por exemplo, se uma aplicação for acessada por alunos, professores e administradores, pode-se ter um //controller// para cada tipo de usuário. Em geral, cada pasta das //views// terá um //controller//.
=== Envio de E-mails ===
Muitos sistemas precisam enviar e-mails. Para isso, preenche-se no ''.env'' variáveis de ambiente para a configuração de e-mail. No caso da TIC, os parâmetros devem ser:
MAIL_DRIVER=smtp
MAIL_HOST=
MAIL_PORT=587
MAIL_USERNAME=
MAIL_PASSWORD=
MAIL_ENCRYPTION=tls
Os campos ''nome_host'', ''nome_usuario'' e ''senha'' devem ser preenchidos de acordo com o endereço de e-mail escolhido. Entre em contato com o suporte para conseguir credenciais de e-mail para seu sistema.
Já o envio de e-mail propriamente dito é feito pelo //controller//. Além disso, é interessante criar uma //view// para formatar o e-mail. Se o sistema for mandar mais do que um tipo de e-mail, é interessante ter um //template// para padronizar os e-mails e uma //view// para cada tipo de e-mail.
Para mandar um e-mail, o //controller// deve ter um código semelhante ao abaixo, onde em ''use'' deve-se passar parâmetros se o e-mail do destinatário, nome do destinatário, assunto, e-mail do remetente e nome do remetente forem variáveis:
try
{
Mail::send('', $params, function ($menssagem) use (...)
{
$menssagem->to('', '')->subject('');
$menssagem->from('', '');
});
...
}
catch(\Exception $exception)
{
...
}
==== Requests ====
Toda vez que um formulário é submetido, é desejado que seus dados sejam validados para que informação espúria ou inválida seja inserida no banco de dados. O banco pode até impedir algumas inconsistências, como campos vazios. Porém, além da validação no banco, é importante haver validação no formulário. Para impedir inconsistências, cria-se um //Request// para cada rota de POST. Esse //Request// é passado como parâmetro para o respectivo método POST. Antes mesmo de o método ser chamado, a validação é feita automaticamente e, se algum dado estiver inválido, a mesma tela será mostrada com as mensagens de erro mostrando os campos errados se tiver seguido as recomendações para centralizar as mensagens de erro no template ao usar o grupo de //middleware// ''web''.
Por padrão, as mensagens de erro de validação serão todas em inglês. Para colocá-las em português brasileiro, é necessário instalar o pacote de português brasileiro como já explicado anteriormente.
Para cada método que for tratar um POST, ou seja, a submissão de um formulário, cria-se uma classe ''Request'' com o seguinte comando:
php artisan make:request
Por padrão, a classe fica em //camel case// com o nome da validação seguido pela palavra ''Request''. Um exemplo poderia ser ''CadastroAlunoRequest''. Os //Requests// ficam na pasta ''app/Http/Requests''.
O nome da classe de //Request// deve ser usado como o tipo do //Request// no método que trata a requisição POST. Então, o método que trata a submissão de um formulário de cadastro de aluno vai ter como parâmetro algo como:
CadastroAlunoRequest $request
Para se pegar os dados vindos da submissão, use o método ''Request::all()'' no parâmetro passado para pegar o vetor associativo com os mesmos.
Já na classe de //Request// criada, o que se deseja é colocar as regras de validação no método ''rules()'', que deve retornar um vetor associativo. Cada chave do vetor é o nome do campo do formulário e seu respectivo valor é uma //string// com as validações necessárias separadas pelo caractere ''|''. Então, se o formulário tiver um campo ''login'' e ele não puder ser ausente, menor do que 21 caracteres e maior do que 5 caracteres, sua regra fica assim:
'login' => 'required|min:6|max:20'
Se tiver dois campos que precisam de confirmação, algo comum para obrigar o usuário a redigitar o e-mail ou a senha a ser criada, o campo de confirmação deve ter o mesmo nome do original seguido de ''_confirmation''. Já no //Request//, o campo original deve ter um ''confirmed'' para assegurar que os dois valores são iguais.
Já se a validação desejada é que um campo seja único numa tabela do banco de dados, a regra é ''unique:''. Desta forma, o //controller// não precisará consultar a tabela após receber os dados para verificar se aquele valor já foi usado antes.
Algo interessante é que se uma ou mais validações falharem e se tiver colocado a impressão de mensagens de erro centralizada no //template// base, será possível ver todos os erros nos dados inseridos no formulário de maneira detalhada, facilitando a correção dos mesmos pelo usuário.
As validações pré-existentes podem ser vistas em https://laravel.com/docs/5.2/validation#available-validation-rules.
É muito comum em sistemas brasileiros desejar validar CNPJ, CPF e CEP e essas regras não existem nas validações pré-existentes. Para criar uma, primeiro cria-se uma classe chamada, por exemplo, de ''CustomValidator'' em ''app/Http''. Ela deve ter o seguinte formato:
Para cada tipo de validação, criam-se dois métodos: um com a regra para validar o dado e outro para mostrar a mensagem de erro. Se o objetivo for criar uma validação para CPF, faz-se algo como:
public function validateCpf($attribute, $cpf, $parameters)
{
if ($cpf é válido) // Colocar aqui a programação que valida o CPF passado.
return TRUE
return FALSE;
}
protected function replaceCpf($message, $attribute, $rule, $parameters)
{
return "O CPF é inválido.";
}
Por último, é necessário publicar o validador customizado em ''app\Providers\AppServiceProvider.php''. No método ''boot()'', coloca-se
Validator::resolver(function($translator, $data, $rules, $messages)
{
return new CustomValidator($translator, $data, $rules, $messages);
});
Assim, agora basta usar ''cpf'' nas regras de validação. Se quiser fazer regras para CNPJ e CPF, basta adicionar um par de métodos de nomenclatura similar para validar o dado de entrada e a mensagem de erro.
Com validação nos //requests// a programação é bastante simplificada porque quase não será necessário fazer ''if''s para a validação de dados de entrada. Quase tudo será tratado automaticamente pelo Laravel.
==== Autenticação ====
Uma maneira fácil de usar autenticação de usuários no Laravel sem ter que se preocupar com a lógica disso é criando uma estrutura semi-pronta que cuida disso. Para isso, o Laravel tem o comando:
php artisan make:auth
Com isso, serão criados //controllers//, //views//, //migrations//, //model//, rotas e estilos para cuidar da questão. Isso deve ser a primeira coisa a ser criada na aplicação se for mesmo usar isso. Afinal, será complicado criar a aplicação toda e só depois colocar um módulo de autenticação.
Algo a se notar é que as //views// não usam o ''Collective''. Isso pode ser incorporado às demais que serão criadas no sistema e não é um problema. O estilo pode ser mudado com outros CSSs.
Algo que necessariamente tem que ser mexido são os caminhos para os estilos, que não serão encontrados ao rodar o sistema do NetBeans e provavelmente de outros endereços. Eles devem ser modificados para usar o método ''asset()''. Além disso, os estilos importam CSSs que estão na //web//, quando o ideal seria baixá-los e colocá-los no sistema, pois podem ficar fora do ar, embora isso seja improvável por serem do Google. Alguns estilos que estão declarados diretamente nas //views// também devem ser separados.
Um problema é que a linguagem da interface terá que ser traduzida manualmente, já que está tudo em inglês e escrito diretamente nas //views//.
Após isso, é preciso configurar o banco de dados e rodar as //migrations//. Para rodar completamente o projeto, é necessário também configurar o envio de e-mail em ''.env'', juntamente com um endereço de remetente geral do sistema em ''config/mail.php'', editando o valor da chave ''from'' com o nome e endereço de e-mail do remetente.
Tendo a parte de autenticação pronta, funcional e já bem testada pelos desenvolvedores do //framework//, agora é mudar os estilos caso necessário e adicionar outros, a página inicial (que não vai ser de Laravel), o título, e continuar a programação do sistema.
Algo interessante a se fazer é criar um projeto //template// só com a autenticação, tirar as referências a Laravel, traduzi-lo, consertar os //links// de estilos e colocar estilos que estão dentro das //views// em CSSs externos, e criar o projeto para o NetBeans. Quando for criar um novo projeto que usa autenticação, é só copiar o projeto e renomear as referências para o nome do projeto final.
Essa parte de autenticação pode ser completamente ignorada se usar o CAS da UFRJ para autenticação de usuários. Obviamente, o CAS só pode ser usado para sistemas internos que serão usados por só por usuários cadastrados na UFRJ e que podem usar a intranet.
==== Middlewares ====
Os //middlewares// processam requisições ao acessar uma rota antes de ir para a rota desejada propriamente dita. Isso é necessário porque certas rotas precisam de autenticação, não podem ser acessadas por determinados usuários, ou para compartilhar variáveis de erro, algo que acontece quando se usa o grupo de //middleware// ''web''. Elas podem ser um grupo ou individual. Uma grupo de //middleware// deve ser usado quando precisar que vários //middlewares// sejam usados pelas mesmas rotas. Se olhar o arquivo ''app/Http/Kernel.php'', verá que o grupo ''web'' possui vários //middlewares//. Mais abaixo, há os //middlewares// individuais.
Para criar um //middleware//, use o comando
php artisan make:middleware
O método ''handle()'' deve ser modificado para o //middleware// ter alguma ação antes de completar a requisição ou mesmo impedi-la. Por padrão, esse método apenas completa a requisição.
Após isso, crie um //middleware// ou um grupo de //middleware// que o contenha. Agora, é só usá-lo.
Se for um //middleware// de CAS, primeiramente é necessário instalar os pacotes necessários via Composer. Após isso, em ''config/app.php'', adicione ''Xavrsl\Cas\CasServiceProvider::class'' a ''providers'' e '''Cas' => Xavrsl\Cas\Facades\Cas::class'' a ''aliases''.
Após isso, crie um //Middleware// semelhante ao abaixo:
Por fim, crie um //middleware// ou grupo de //middleware// chamado ''cas'' que contenha a classe nova, que será algo como: ''\App\Http\Middleware\CasMiddleware::class''.
Nas versões do Laravel a partir da 5.3 não é preciso colocar o ''web'' como //middleware// porque ele já vem automaticamente para todas as rotas por ser muito usado.
==== Sessões ====
Sessões servem para salvar dados de uma instância do sistema que está rodando no navegador. Em geral, é muito utilizado para salvar dados de um usuário logado e saber se há um usuário válido logado.
Para colocar dados na sessão, faz-se:
Session::put(', '')
Já para recuperar dados da sessão ou saber se há uma sessão válida, faz-se:
Session::get('')
Com isso, pode-se saber se há uma chave com aquele nome ou se o valor que corresponde aquela chave é válido ou o procurado.
Para finalizar uma variável de sessão, faz-se:
Session::forget('')
Por fim, para finalizar todas as sessões, faz-se:
Session::flush()
==== CAS ====
Além do que já foi dito, são precisos mais alguns passos para poder usar o CAS em sua aplicação. Primeiramente, deve-se publicar a funcionalidade do CAS baixada no diretório ''vendor'':
php artisan vendor:publish
Depois, em ''.env'', deve-se colocar:
CAS_HOSTNAME=
CAS_URI=
Se for usar o CAS da TIC, a configuração fica apenas com o ''CAS_HOSTNAME=cas.tic.ufrj.br''. Já se for o da UFRJ, também só precisa de ''CAS_HOSTNAME=cas.ufrj.br''.
Toda rota que precisar passar pela autenticação do CAS precisa estar dentro do grupo de //middleware// ''cas''.
Toda a vez que precisar saber no //controller// se há um usuário autenticado no CAS, faz-se:
Cas::isAuthenticated()
Já para finalizar a sessão no CAS, provavelmente quando se desejar finalizar a sessão no sistema (//log out//) que o usa, faz-se:
Cas::logout(['service' => asset('')]);
onde '''' é a rota para onde o sistema deve ser redirecionado após o //log out//.
==== Funções Auxiliares ====
O Laravel usa várias funções auxiliares globais, conhecidas como //helper functions//. Pode ser interessante criá-las para seu projeto sem ter que criar uma classe com métodos estáticos. Isso simplifica a sintaxe e, por sua vez, a programação.
Para fazê-lo, crie um arquivo PHP, por exemplo ''helpers.php'' em ''app''. Para que as funções possam ser usadas sem //imports// ou algo do gênero, precisam ser auto-carregadas. Para isso, coloque em na seção ''autoload'' do ''composer.json'' algo como:
"files":
[
"app/helpers.php"
]
Para que o Laravel detecte as funções, é necessário dar o comando ''composer dump-auto''.
==== Dump and Die ====
Uma maneira costumeira de se depurar em PHP é dar ''var_dump()'', ''print_r()'' ou ''echo'' em uma variável e depois o comando ''die'' para parar a execução do sistema após imprimir o valor, com maior ou menor detalhe, de uma variável no navegador. O Laravel facilita isso com o //dump and die// ou ''dd()'', que irá fazer um //dump// no objeto em questão e parar a aplicação.
==== Recomendações Adicionais ====
* Cuidado com os //name spaces//. Se for usar uma classe, é preciso importá-la usando o comando ''use'' no cabeçalho da classe que vai usá-la. Senão, o Laravel vai achar que a classe está no //name space// da classe sendo editada. Se for uma classe do PHP como ''Exception'' ou ''String'', é necessário chamá-las com ''\Exception'' e ''\String'', respectivamente. Senão, o Laravel achará que essas classes estão dentro do //name space// da classe sendo editada.
* Se for usar a autenticação criada pelo Laravel, seu projeto deve começar daí. Posteriormente, crie as //migrations// e //models//. Só depois comece a implementação do sistema propriamente dita.
* Dependendo do que for fazer em seu //controller//, redirecionamentos podem ser muito úteis. O método ''redirect'' ou o //facade// ''Redirect'' devem ser usados. Em http://laraveldaily.com/all-about-redirects-in-laravel-5/ há várias maneiras de se lidar com redirecionamentos.
* Sempre use as versões mais recentes do PHP 5 e Laravel 5, seja por questôes de segurança, seja por novas funcionalidades, principalmente no Laravel. Se lançarem a versão 6 do Laravel, provavelmente terá muitas diferenças em relação à 5, assim como aconteceu entre a 4 e a 5, o que poderá tornar difícil seguir este tutorial.
* Use a classe ''Carbon'' para tratar data e hora por possuir vários métodos extremamente úteis. Para usá-la, apenas importe ''Carbon\Carbon'' por ela já vir instalada com o Laravel.
===== Mail =====
"Laravel provides a clean, simple API over the popular SwiftMailer library with drivers for SMTP, Mailgun, SparkPost, Amazon SES, PHP's mail function, and sendmail, allowing you to quickly get started sending mail through a local or cloud based service of your choice."
[[infotic:laravel:mail|Mail com Laravel]]