Matheus Marabesi Michael Douglas
Novatec
© Novatec Editora Ltda. 2017. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates PY20171020 Revisão gramatical: Tássia Carvalho Editoração eletrônica: Carolina Kuwabata Capa: Carolina Kuwabata ISBN: 978-85-7522-628-5 Histórico de impressões: Outubro/2017
Primeira edição
Novatec Editora Ltda. Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 Email: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec
capítulo 1
Introdução
Antes de iniciar esta jornada, gostaria de compartilhar nossa experiência com o Laravel. Conhecemos o Laravel na versão 4.2 e a primeira impressão que tivemos do framework foi que não atenderia às nossas necessidades. Nesse primeiro contato, ocorrido a partir de um projeto de portal já existente na empresa em que trabalhávamos na época, o Laravel que analisamos possuía uma estrutura que foi bem decepcionante de início; no entanto, o que não sabíamos é que o problema não era o framework, e sim a forma como foi implementado na criação desse projeto. Com o passar do tempo, tivemos de fornecer o suporte a essa ferramenta, e foi uma verdadeira aventura cuidar do que já existia desse projeto, pois, como mencionado, a estrutura não agradava e nós acreditávamos fielmente que o problema era o Laravel. Este foi o segundo ponto da aventura com o Laravel: nossas experiências anteriores ocorreram com os frameworks Symfony e Zend Framework, os quais, claro, não tínhamos nenhum problema para utilizar. E, no meio de todas as conversas e debates que fizemos com relação ao Laravel, encontramos algo bastante interessante para nós, o fato de o Laravel ter se baseado no Symfony para a criação de sua estrutura. Após essa descoberta e esquecendo tudo o que aconteceu quando utilizávamos a versão 4.2, chegamos ao ponto final de nossas discussões: se é baseado no framework que conhecemos, vamos dar uma nova chance a ele, mas dessa vez na versão 5. Para prosseguir, tenha em mente que o foco deste livro não são discussões como: • Laravel é o melhor framework comparado a outros? • Devo desistir do meu framework favorito e utilizar o Laravel? Depois de já termos dado um ponto final à discussão de “devo ou não utilizar o Laravel?”, em certo momento, por decisão da diretoria da empresa, surgiu a oportunidade de reescrita dos projetos de portais da empresa, com o que na época 15
16
Aprendendo Laravel
ficamos muitos felizes. No entanto, como nem tudo é um mar de rosas, eles não queriam jogar fora o projeto antigo em que haviam investido tanto dinheiro para a empresa terceira que o criara. Com isso, foi dada a cartada final e tivemos de aceitar de uma vez por todas o Laravel. Com a oportunidade de escrever quase que do zero o portal de utilização dos alunos da empresa, demos andamento ao projeto e, conforme ele andava, começamos a perceber as facilidades que o Laravel traz, as quais consistem em uma gama de ferramentas que nos ajudou e muito na entrega do projeto. Inicialmente, ficou evidente que a curva de aprendizado da equipe era consideravelmente mais baixa. A documentação era clara no que você precisava, a implementação de bibliotecas via Composer era bem simples, a criação de serviços REST era mais fácil, entre outros pontos que deixavam clara a facilidade. Enfim, conseguimos entregar o projeto no prazo com tudo funcionando, sem problema algum. No entanto, o que havíamos criado até então era uma subcamada do projeto principal desenvolvido pela empresa terceira; não se esqueça de que não foi permitido jogar todo o legado Laravel que já existia, e sim criar essa nova versão que rodaria junto com a versão legada do software. Entretanto, como conseguimos aperfeiçoar o conhecimento no Laravel e também entregamos exatamente o que eles queriam, recebemos a seguinte notícia, que hoje podemos classificar como ótima: Vocês podem reescrever tudo o que foi desenvolvido para o portal e jogar o legado fora. E podemos afirmar que, após tudo o que foi contado a você, conseguimos então perceber o poder total do Laravel e o que ele poderia trazer de benefícios ao nosso dia a dia. Dado todo o contexto, caro leitor, tomamos a iniciativa de ajudar todos que desejam entrar de cabeça e conhecer mais sobre esse framework, que acabou se tornando tão querido da comunidade e em tão pouco tempo é considerado por muitos a melhor escolha.
1.1 Qual o propósito deste livro? Após essa introdução, você poderá se perguntar: Legal, mas devo utilizar o Laravel? Em nossa jornada, apresentaremos todas as facilidades e pretendemos deixá-lo com aquela vontade de executar a instalação do Laravel e sair codificando com ele. Apenas para reforçar ainda mais seu interesse na utilização do Laravel, apresentaremos a seguir um case de sucesso. Caso você ainda esteja cético ou se ainda não
Capítulo 1 ■ Introdução
17
sabia da existência de algo robusto e grande feito em Laravel, fique sabendo que existe um projeto que é um ótimo exemplo da robustez do programa, o e-commerce da Leroy Merlin. Esse é um projeto de grande porte feito em Laravel e que dispensa apresentação sobre sua qualidade. Caso tenha descoberto isso lendo este livro, não deixe de acessar o site da Leroy Merlin e visualizar a loja. Agora que já sabe sobre esse case, talvez consigamos convencê-lo a utilizar o Laravel em vez do Zend Framework, Symfony etc. Você já sabe sobre nossa experiência com o Laravel e sobre o case da Leroy, então agora o guiaremos nessa jornada e teremos a oportunidade de ajudá-lo a aprender bastante sobre o Laravel. O que nós esperamos é que perceba no decorrer do livro que tentamos ao máximo atender a todos os tópicos do Laravel para que a obra seja proveitosa tanto para desenvolvedores avançados quanto para quem é iniciante. No final do livro, ensinaremos a utilizar a Laravel PagSeguro, uma biblioteca de autoria do Michael para interação com o PagSeguro. Aproveitaremos para comentar como foi a experiência de criar uma biblioteca para a comunidade e, de quebra, quem sabe deixaremos em você aquela vontade de criar a sua biblioteca, ou até mesmo de manter vivo o projeto Laravel PagSeguro! Ao final da leitura, é esperado que você já esteja apto a: baixar, instalar, codificar e subir seu projeto Laravel para produção e, mais além, que possa, junto conosco, defender a utilização do framework na comunidade PHP.
1.2 Iniciando sua vida com o Laravel Antes de prosseguir com os estudos em Laravel, gostaríamos de avisar que o Capítulo 1 foi especialmente pensado para ajudar quem ainda não se sente tão confiante com algumas tecnologias que o Laravel possui. Nesse início, queremos ajudar você que precisa de um guia inicial para se tornar um futuro Artesão Laravel. Lembre-se, o Laravel possui algumas tecnologias que compõem sua estrutura, tais como: • Composer • Protocolo HTTP • Git • REST • Namespace • JSON
18
Aprendendo Laravel
Agora, caso já seja um desenvolvedor PHP que domine essas tecnologias, talvez este início não agregue muito. A maior preocupação deste capítulo é fazer com que quem não domine algum dos assuntos mencionados consiga entender o básico para prosseguir com os estudos e tirar proveito do livro. Sendo assim, se desejar, pule para o Capítulo 2, no qual aprenderemos a instalar o Laravel e a criar nossa primeira aplicação.
1.3 Composer Primeiro, se não utiliza o Composer em seu projeto, posso dizer que você tem coragem. Hoje em dia, a maioria, se não todas as bibliotecas PHP, tende a estar no controle do Composer, que nada mais é do que uma ferramenta de gerenciamento de dependência em PHP. Ou seja, se levarmos para um conceito mais famoso que é o do Linux, é tão legal quanto executar apt-get install php7 ou apt-get install php5 e como mágica ele instalar e já deixar tudo configurado. Utilizando ainda esse exemplo, é legal realizar um apt-get upgrade e atualizar tudo sem dor de cabeça? Apenas se lembre do detalhe de que o Composer é um gerenciador de pacotes para PHP e Yum e/ou APT são para Linux. Agora imagine todo esse poder em sua estrutura PHP: não seria um tanto quanto legal? Com o Composer, você terá essa facilidade, pois a partir do momento que passa a utilizá-lo, ele vai permitir que declare as bibliotecas de seu projeto em um arquivo simples de manter e utilizar, o composer.json. Veja a seguir no exemplo da Listagem 1.1:
Listagem 1.1 (composer.json) – Exemplo de arquivo de configuração do Composer { "name": "Livro Laravel", "description": "Livro de Laravel", "authors": [ { "name": "Laravel", "email": "laravel@livrolaravel.com.br" } ] }
Capítulo 1 ■ Introdução
19
O Composer vai ler o arquivo composer.json que está na raiz do seu projeto e dará a você o poder de instalação e atualização das bibliotecas de dependência do seu projeto. Além disso, também pode ajudá-lo a travar a versão da biblioteca que estiver utilizando apenas passando o número da versão que deseja utilizar e que funcione com o seu sistema. Para ajudá-lo a entender melhor o que estamos tentando dizer, imagine que tenha baixado uma biblioteca de PDF no ano retrasado e soube que a empresa ou comunidade que a mantém gerou uma versão nova e com isso, então, você deseja atualizar a sua biblioteca de PDF para essa nova versão. Agora imagine só o problema que teria se fosse realizar tudo isso manualmente? No entanto, graças ao Composer, realizar essa tarefa é bem simples, pois basta que altere a versão da biblioteca no arquivo composer.json e então execute o comando de atualização de bibliotecas do Composer. Como mágica, terá a nova versão da biblioteca! Vamos agora então baixar a biblioteca MPDF que serve para conversão de HTML para PDF e a instalação será feita via Composer. Você perceberá que, ao baixar a MPDF, o seu composer.json ficará marcado com a versão que baixou na época de criação do seu projeto. A versão utilizada nos exemplos do livro é a 6.0. Para o nosso exemplo, crie uma pasta chamada livrolaravel e execute o comando: $ composer require mpdf/mpdf
Após a execução do comando, repare como ficou o arquivo composer.json na Listagem 1.2:
Listagem 1.2 (composer.json) – Exemplo de arquivo de configuração do Composer com a biblioteca MPDF { "name": "Livro Laravel", "description": "Livro de Laravel", "require": { "mpdf/mpdf": "^6.0" }, "authors": [ { "name": "Laravel", "email": "laravel@livrolaravel.com.br" } ] }
20
Aprendendo Laravel
Caso tenha utilizado o composer.json de exemplo do livro, perceba que o que foi alterado em nosso arquivo de composer.json é a inserção da nova linha contendo a biblioteca MPDF (https://packagist.org/packages/mpdf/mpdf). Algo novo que também ocorre ao baixar o MPDF é a geração do arquivo composer.lock, que serve para travar as versões utilizadas no projeto. Isso significa que, se outro desenvolvedor quiser configurar o projeto, vai baixar exatamente as mesmas versões de dependências. A MPDF é muito utilizada em projetos que precisam transformar páginas HTML em PDF. Por exemplo, em empresas que geram o contrato a partir de HTMLs específicos e que em seguida precisam mandar o PDF para seus clientes, a MPDF pode ser uma boa escolha.
1.3.1 Gerenciando as dependências do seu projeto com Composer Depois de tudo que foi comentado, talvez você tenha concluído que o Composer no final das contas é um gestor de dependência. Caso tenha chegado a essa conclusão, parabéns, pois você está certo, mas talvez fique curioso para saber de onde ele obtém os pacotes. Antes de explicar de onde o Composer obtém os pacotes, é necessário saber como pesquisar um pacote e executar o comando em Composer para instalar essa funcionalidade. Para isso, será apresentado o Browse Packages. Acesse o site do Composer no link https://getcomposer.org. Ao acessar o link, clique no botão Browse Packages e veja a estrutura da tela, conforme mostra a Figura 1.1.
Figura 1.1 – Tela de demonstração para link do Browse Packages.
Capítulo 1 ■ Introdução
21
Depois de clicar no link, será aberto o Packagist. Esse é o local responsável por manter as bibliotecas e permite também que você realize busca das bibliotecas.
1.3.2 Laravel PagSeguro A Laravel PagSeguro é uma biblioteca responsável por consumir os serviços do PagSeguro e fornece uma forma bem simples de fazer isso, pois ela só precisa que configure sua conta e token e, a partir disso, você será capaz de gerar pagamentos, notificações, transações da sua loja etc. Em nossos exemplos, utilizaremos a biblioteca Laravel PagSeguro. Caso realize a pesquisa da biblioteca no campo de busca, como é demonstrado na Figura 1.2, poderá visualizar e também clicar para ler um pouco mais sobre a biblioteca Laravel PagSeguro.
Figura 1.2 – Tela de demonstração de pesquisa realizada para a biblioteca Laravel PagSeguro.
Caso clique e abra as informações da biblioteca, inicialmente o mais importante é que possamos não apenas baixar a Laravel PagSeguro, mas também instalar outras bibliotecas. Para isso, instale o Composer em seu sistema, o que aprenderemos a seguir.
1.3.3 Instalando o Composer A instalação do Composer é bem simples, basta realizar o download no site do Composer e decidir se deseja usar o Composer localmente, o que pode ser bom para quem não tem permissão para mover o arquivo. Agora, se você tem permissão, vamos ensinar a instalar e configurar o Composer para os sistemas Windows, Linux e Mac.
22
Aprendendo Laravel
1.3.4 Instalando o Composer no Windows A forma mais simples de instalar o Composer no Windows é utilizar o composerSetup.exe, que pode ser baixado no link https://getcomposer.org/Composer-Setup.exe. Ao executar o Composer-Setup, você já o terá instalado em seu sistema operacional; além disso, o executável já configura a variável de ambiente, executando o comando composer em seu prompt de comando, como mostra a Figura 1.3.
Figura 1.3 – Tela com a execução do comando composer no Windows.
1.3.5 Instalando o Composer no Linux e Mac Para instalar o composer no Mac e no Linux, basta executar: curl –s https://getcomposer.org /installer | php
Após a execução desse comando, você receberá uma informação de sucesso, algo como: Composer successfully installed to: /Users/Michael/composer.phar Use it: php composer.phar.
Desse modo, já será possível executar em seu terminal o comando php composer.phar, mas utilizar o Composer dessa maneira é bem ruim, pois ele baixou o arquivo de execução do Composer localmente, ou seja, não será possível executar o comando Composer em outro projeto. Sendo assim instalar localmente pode não ser tão interessante, pois o composer.phar fará parte apenas do projeto que o instalou.
Capítulo 1 ■ Introdução
23
Talvez você se pergunte por que existe essa opção. É simples responder a esse questionamento: existem empresas que possuem sistemas legados que não utilizam o Composer. E algum desenvolvedor desse sistema legado pode não se sentir muito confortável em deixar o Composer globalmente no sistema, mas utilizar o Composer em um outro projeto específico que a empresa possua. Justamente por esse motivo que é interessante o Composer deixar que você o utilize apenas em um projeto específico. O mais convencional, porém, é instalar o Composer de forma global no seu sistema. E isso é bem simples, tanto no Mac quanto no Linux. Para instalar o Composer de forma global em seu sistema, você pode, por exemplo, criar um link simbólico até o Composer recém-baixado da seguinte maneira: sudo ln –s ~/composer.phar /usr/local/bin/composer
Ou também pode mover o arquivo composer.phar para executar na pasta bin global do seu sistema: sudo mv composer.phar /usr/local/bin/composer
Para que você confirme que deixou o Composer global, execute em seu terminal o seguinte comando: composer self-update
1.4 Git Como o intuito do livro não é torná-lo um especialista em Git, e sim ensinar Laravel, foi reservado um pequeno espaço para você saber como controlar a versão do seu projeto com o Git e entender um pouco sobre a união do Git com o Composer. Você sabia que o Git não é o único sistema de controle de versão? Existem outras soluções que também podem ser utilizadas para controlar a versão do seu código, mas lembre-se: em nossa jornada Laravel, o Git será o seu maior parceiro! No entanto, gostaríamos de pelo menos mencionar o nome dessas outras soluções porque elas podem também aparecer no seu dia a dia e você talvez precise utilizá-las: • CVS • Mercurial • SVN
24
Aprendendo Laravel
1.4.1 Instalando o Git no Linux A instalação do Git no Linux não é complicada, sendo necessário que você o instale a partir do instalador binário. Quem utiliza o gerenciamento de pacotes Yum, que é o caso da Fedora, deverá executar os seguintes comandos: $ yum update $ yum install git-core
Agora se está utilizando as distribuições baseadas no Debian, como é o caso do Ubuntu, você executará os seguintes comandos: $ apt-get update $ apt-get install git
Para verificar se a instalação ocorreu com sucesso, execute o comando de verificação de versão em seu terminal da seguinte maneira: $ git -–version
1.4.2 Instalando o Git no Windows Atenção: se você já tem o Git instalado, talvez este capítulo não seja tão interessante, mas, caso ainda não tenha, será de grande ajuda. Para realizar a instalação do Git no Windows, acesse o link https://git-scm.com/ download/win, escolha o instalador do Git para a arquitetura do seu sistema, que pode ser de 32-bits ou 64-bits, e clique na opção que atende à arquitetura do seu sistema. Quando terminar o download, você deverá executá-lo e então será aberta a opção ilustrada na Figura 1.4; você deverá clicar em Next para prosseguir com a instalação. Agora que já prosseguiu, será exibida uma tela com a licença do Git, como ilustrado na Figura 1.5 (muitos não vão ler essa tela, mesmo sendo importante). Agora prossiga apertando Next novamente. A próxima tela, ilustrada na Figura 1.6, conterá os componentes que você pode selecionar em sua instalação; é possível escolher entre uma opção ou mais de uma para não ficar selecionando uma a uma. Repare que, ao clicar na opção pai, as filhas serão selecionadas como ícones adicionais, mas caso queira apenas uma opção filha basta clicar naquela que mais o agrade. Você não é obrigado a selecionar, mas atente-se ao fato de que, se não selecionar, pode não ter alguns benefícios que esses itens trazem consigo, pois cada item pode conter uma funcionalidade específica em seu sistema, a qual facilitará a utilização do Git.
Capítulo 1 ■ Introdução
25
Figura 1.4 – Tela inicial da instalação do Git no Windows.
Figura 1.5 – Tela contendo as informações de licença GNU utilizada no Git.
Cada item será explicado, e cabe a você decidir se concorda em deixá-lo selecionado ou não. No entanto, caso opte por não selecioná-lo, é possível reinstalar o Git Bash e selecionar as opções que vão trazer mais benefícios e facilidades no seu dia a dia.
26
Aprendendo Laravel
Figura 1.6 – Tela contendo a escolha de componentes para o seu sistema.
Explicação dos itens de componentes: • Ícones adicionais – Os ícones adicionais servem para que o Git Bash seja lançado quando você iniciar o seu sistema ou para a criação de um ícone de inicialização do Git Bash. • Quando iniciar o sistema – Opção para inicializar o Git junto ao sistema. • Deixar na área de trabalho – Opção que criará um ícone em sua área de trabalho. • Integração com o Windows Explorer – Integração com Windows Explorer para o Git Bash e para o Git GUI. • Git Bash – Integrará o Git Bash ao Windows Explorer. • Git GUI – Integrará o Git GUI ao Windows Explorer. • Associar os arquivos com a extensão (.git) ao editor-padrão do sistema – Essa opção habilita os arquivos da extensão .git. Abra no editor que estiver configurado como padrão de abertura de arquivos em seu sistema. Ou seja, ao clicar em um arquivo que contenha a extensão mencionada, ele será aberto, por exemplo, no Sublime, se for o editor padrão de arquivo do seu sistema. • Associar os arquivos com a extensão (.sh) para execução no Bash – Essa opção habilita que, ao abrir um arquivo (.sh), ele seja executado pelo Bash que você está instalando nesse momento.
Capítulo 1 ■ Introdução
27
Agora que já conhece as opções, cabe a você, e não a nós, escolher o que é necessário, afinal, cada um sabe o que é melhor para o seu caso. Em nosso exemplo foram selecionados todos, pois, caso seja necessário explicar algum item, nós já o teremos instalado e configurado. A próxima tela aberta será sobre uma pergunta: se você gostaria de usar o Git na linha de comando. Será então perguntado sobre três opções para escolha de execução de comandos, como ilustrado na Figura 1.7.
Figura 1.7 – Tela contendo a escolha de linha de comando.
Explicação dos itens de linha de comando: • Usar apenas o Git Bash – Essa opção permite usar apenas os comandos Unix no Git Bash, ou seja, se tentar executar os comandos Unix no prompt de comando do Windows, não conseguirá. • Executar o Git a partir do prompt de comandos do Windows – Essa opção permite executar o Git no prompt de comando do Windows, ou seja, é possível utilizar o comando Git clone no prompt sem nenhuma dor de cabeça. Porém, você não conseguirá executar os comandos Unix com essa opção, o que pode ser ruim, pois nos exemplos que há na internet geralmente o autor utiliza comandos Unix e você pode acabar não tendo a mesma experiência ao executá-los. • Executar o Git e incluir os comandos Unix no prompt de comandos do Windows – Essa opção permitirá executar os comandos Unix pelo prompt de comando do Windows. No entanto, alguns comandos do Windows serão substituídos.
28
Aprendendo Laravel
Como podemos ver na Figura 1.7, existe um texto em vermelho informando sobre a troca de comandos. No caso, ela informa sobre os comandos find e sort que são do Windows. Entretanto, tirando essas particularidades, você terá um grande poder em seu prompt de comando, pois poderá executar comandos Unix sem problema. Em nosso exemplo será escolhida a terceira opção, pois, caso você precise executar os comandos que serão passados no livro, não terá problema algum para acompanhar. A próxima opção, como ilustrado na Figura 1.8, perguntará qual cliente shell você deseja utilizar para o seu Git. Talvez alguns já tenham passado pela experiência de ter uma instância AWS, por exemplo, na qual existe a opção acessar o servidor via SSH. No GNU/Linux, basta executar no terminal o comando: ssh usuario@enderecodoservidor
Caso execute o comando no Linux e retorne command not found, será necessário instalar o SSH desta forma: apt-get update e apt-get install ssh
Agora, caso você esteja no Windows, será instalado, por exemplo, o OpenSSH. E, caso selecione essa opção ou a do Plink, conseguirá acessar servidores via SSH.
Figura 1.8 – Tela contendo a escolha do cliente de SSH.
Agora que escolheu o seu cliente SSH, deverá em seguida escolher o tipo de quebra de linha que seu sistema utilizará. Talvez você já saiba que o Windows e sistemas Linux e Mac utilizam a quebra de linha de forma diferenciada.
Capítulo 1 ■ Introdução
29
Quem estiver utilizando o Windows e escrever seu código com quebras de linhas no padrão Windows pode, ao salvar esse arquivo e enviar a usuários de Mac ou Linux, gerar problemas para os usuários que consumirem, por exemplo, esse script. No entanto, tenha calma com a escolha correta, como exemplificado na Figura 1.9, e não terá problemas.
Figura 1.9 – Tela contendo a escolha da quebra de linhas.
Continuando com a instalação, será perguntado a você com qual emulador de terminal gostaria de trabalhar. Sabemos que o padrão atual em sua máquina talvez seja o prompt de comando do Windows. Repare isso na Figura 1.10.
Figura 1.10 – Tela contendo a escolha do emulador de terminal.
30
Aprendendo Laravel
Explicação dos itens de escolha do emulador de terminal: • Usar Mintty como emulador de terminal – Essa opção permite instalar o programa que emula terminal conhecido como Mintty. A partir disso, você utilizará essa interface para executar seus comandos. • Usar o console padrão do Windows – Essa opção usa como padrão o CMD (Command Prompt Windows) para execução dos comandos. Em nosso exemplo foi escolhida a primeira opção, mas, caso você goste do CMD da Microsoft, não terá problema algum para executar os comandos junto a ele caso selecione a outra opção. Sendo assim, em seguida será perguntado se deseja ativar uma configuração experimental de performance, o Tweaks. Essa opção, caso marcada, vai ativar o cache de arquivos como ilustrado na Figura 1.11. Em nosso exemplo, essa opção ficará ativa.
Figura 1.11 – Tela contendo a escolha para ativar o cache de arquivos.
Finalmente, após tantas telas e Next, você verá que o Git começará a ser instalado em seu sistema. Sabemos que alguns podem ter pressionado Next sem ler as opções; assim, caso queiram ajustar algo lido posteriormente, não se preocupem, pois ao chamar o executável, será possível instalar o Git novamente. Quando chegar na tela da Figura 1.12, surgirá uma janela nova informando que o Git será instalado. A partir desse momento, você poderá trabalhar com o Git e executar todos os comandos que serão explicados no livro sem grandes problemas, mesmo que esteja em ambiente Windows.
Capítulo 1 ■ Introdução
31
Figura 1.12 – Etapa final de instalação do Git no Windows.
Ao término dessa etapa, será exibida uma tela contendo a informação de que o Git foi instalado com sucesso. Caso não deseje ler as notas de lançamento, basta desmarcar a opção e apertar em concluir, como ilustrado na Figura 1.13.
Figura 1.13 – Conclusão da instalação do Git.
A partir de agora, você poderá chamar o Git clicando no ícone dele. Dependendo de como foi instalado em sua máquina, verá que, ao chamá-lo, ele abrirá a tela ilustrada na Figura 1.14. Se for apresentada a tela mencionada, então você poderá executar os comandos apresentados mais à frente em nossa jornada Laravel.
32
Aprendendo Laravel
Figura 1.14 – O Git foi instalado com sucesso.
1.4.3 Instalando o Git no Mac A instalação do Git é bem simples no Mac, e, assim como no Windows, podemos utilizar a interface gráfica para instalá-lo. No caso do Mac, é o Git OS X, que pode ser baixado no link http://sourceforge.net/projects/git-osx-installer. Ao baixar e executar o arquivo, será aberta a tela de instalação do Git para o Mac, como ilustrado na Figura 1.15.
Figura 1.15 – Etapa inicial de instalação do Git no Mac.
Na próxima tela, será perguntado qual localização a instalação deve utilizar. No caso, o padrão a se utilizar é no disco “MACINTOSH”, como ilustrado na Figura 1.16.
Capítulo 1 ■ Introdução
33
Figura 1.16 – Escolha de disco no Mac.
Na próxima tela, você verá que é exibido o progresso de instalação, conforme a Figura 1.17.
Figura 1.17 – Gravação do Git no disco.
Caso todo o processo tenha ocorrido sem erros, surgirá a última tela que confirma a instalação do Git em seu Mac, como ilustrado na Figura 1.18. Existe outra maneira de instalar o Git no Mac, que é via MacPorts (http://www. macports.org). Execute o seguinte comando em seu terminal: $ sudo port install git-core +gitweb
34
Aprendendo Laravel
Figura 1.18 – Finalização da instalação do Git.
Para confirmar a instalação, você pode executar no terminal o comando: $ git –version
Se a versão do Git retornou, então sua instalação ocorreu com sucesso e pronta para uso. O nosso foco foi ajudá-lo a deixar o Git rodando no seu sistema e pronto para utilização, mas, se ainda houver dificuldades com o Git ou caso não tenha trabalhado com ele, ainda recomendamos este ótimo tutorial: http://rogerdudler.github.io/git-guide/index.pt_BR.html
1.5 REST Vamos aprender um pouco sobre o REST (Transferência de Estado Representacional) e como utilizar o Laravel a fim de obter uma boa solução para comunicação heterogênea de aplicações para aplicações. O que você precisa ter em mente é que com REST nós abstraímos a nossa interface de usuário com nossos agentes externos e, com isso, podemos eliminar, por exemplo, um formulário de submissão de dados para os nossos clientes. Para que fique mais fácil de entender, imagine que você precise deixar outro sistema fazer o login no seu sistema. Inicialmente poderíamos pensar em algo gráfico como solução. Ou seja, nós, desenvolvedores web, geraríamos um HTML que possa ser usado pelos nossos clientes.
Capítulo 1 ■ Introdução
35
No entanto, veremos no decorrer do capítulo que fazer esse HTML para integração com o nosso sistema não é necessário já que vamos utilizar o conceito de serviços com REST, ou seja, em vez de necessitarmos das tais telas mencionadas anteriormente, passaremos essa responsabilidade para os nossos serviços que utilizarão a comunicação via HTTP, aproveitando tudo que o protocolo já oferece. Nesse modelo, o que criamos é uma interface de comunicação com nossos agentes externos sob o protocolo HTTP e, ao criar seus serviços, você precisará se preocupar em oferecer uma API coesa e, se possível, documentada. Um exemplo que podemos citar para ajudar a finalizar o entendimento básico do que é o serviço seria mencionar a API de login do Facebook. Hoje em dia, muitas empresas se comunicam com o Facebook nessa camada de login para autenticar os usuários em suas ferramentas. Pensando assim, nada impede que sua empresa também siga esse padrão e crie uma API de autenticação de usuários, não necessitando gerar um HTML de login, o que por várias vezes pode não ser muito customizável. A documentação Facebook para web pode ser encontrada neste link: https://developers.facebook.com/docs/web.
Ainda temos, porém, a seguinte questão a responder: onde o Laravel entra em tudo isso? Bom, uma das vantagens do Laravel é o fato de ele possuir a facilidade da utilização do padrão MVC. Além disso, ele apresenta um ótimo sistema de roteamento e, graças a ele, a curva de implementação dos seus serviços já foi pensada. Sendo assim, você poderá separar, com muita facilidade, tanto a camada interna do seu sistema, como a área administrativa, site, portal etc., e já em seguida poderá, com certa facilidade, expor essa lógica como serviço para seus clientes. Um pequeno exercício: Imagine que em sua empresa haja um sistema de cadastro,
listagem, edição e exclusão de dados financeiros. E chegou até você uma demanda para integrar a sua aplicação a um ambiente de um parceiro. Ao analisar a demanda, você chegou a seguinte conclusão: o ambiente é completamente diferente da sua estrutura e você não terá acesso de nível de código a esse sistema. Tente imaginar um cenário de integração e o que seria necessário para realizar essa tarefa. Calma, pois, caso não consiga imaginar o cenário, mais à frente acreditamos que já será capaz.
36
Aprendendo Laravel
1.5.1 Protocolo HTTP Antes de nos aprofundarmos mais em REST, você precisará entender pelo menos o básico do protocolo HTTP. Nesse primeiro momento, gostaríamos de explicar que o foco maior nos próximos capítulos será o de responder sobre como utilizar o Laravel para criar aplicações MVC, portais e suas APIs, tanto públicas como privadas. Sendo assim, não entraremos em assuntos muito técnicos sobre o protocolo HTTP, e abordaremos apenas o básico para ajudá-lo nessa aventura. O protocolo HTTP em sua essência consiste de um conjunto de definições Web Standards HTTP e URIs, fazendo com que exista uma comunicação entre sistemas. Ou seja, permite que se realize a transferência de dados entre redes de computadores. No caso de nossas páginas web, significa que é realizada uma troca de informação na World Wide Web, e que no final das contas estamos transferindo um hipertexto, o qual no caso é nossa página HTML. O que nos interessa é entendermos que o protocolo HTTP é utilizado para transferência de dados de um servidor para a internet, no caso, o seu computador. O protocolo se baseia no conceito de envio de requisição (Request HTTP) e resposta (Response HTTP). Essa questão da requisição e resposta é de suma importância para você que deseja trabalhar com Webservices REST. Para ajudar ainda mais quem ainda não domina muito o assunto, podemos ver um exemplo de requisição e resposta a partir do navegador. Para ver as requisições de uma página, abra o console de desenvolvedor com o Chrome a partir do Developer Tools e no Firefox utilize o Firebug. Tanto no Chrome como no Firefox é possível visualizar o monitoramento de rede a partir das ferramentas mencionadas. Caso você tenha inspecionado as requisições a partir das ferramentas mencionadas na aba de rede, talvez tenha reparado que tudo o que está sendo executado no final das contas se resume em uma solicitação de dados ao servidor, e o que ocorre é uma resposta a essa requisição.
1.5.2 Componentes importantes do HTTP Após nossa introdução no protocolo, talvez tenha ficado um pouco mais claro que estamos falando de um mundo grande e pouco explorado. Precisamos a partir de agora descobrir que não existe apenas POST e GET para se trabalhar, e sim uma verdadeira gama de possibilidades de separações lógicas para as nossas futuras APIs. Você já aprendeu um pouco sobre como o protocolo HTTP trabalha e que sua essência se baseia no fato de possuirmos uma requisição e uma resposta. Vamos,
Capítulo 1 ■ Introdução
37
então, mergulhar um pouco mais nesse mundo e descobrir que existem separações que ditam a regra do fluxo de como os dados trafegarão em nossos serviços. Em sua essência, uma requisição possui componentes importantes tais como: substantivos, verbos e tipos de conteúdo. Na maioria dos casos, construiremos nossos serviços baseados no conceito RESTful. Para entender o que é o RESTful, precisamos quebrar ainda mais o protocolo HTTP, para que finalmente possamos dizer que criamos um serviço RESTful em Laravel. No próximo tópico entraremos em detalhes sobre recursos e logo em seguida falaremos sobre operações.
1.5.3 Recursos É bastante comum que você já tenha acessado alguns sites como http://google.com, e talvez, após a leitura dos primeiros tópicos do Capítulo 1, tenha tido a curiosidade de inspecionar a requisição. E, com isso, tenha analisado que, ao inspecionar a requisição, na verdade estamos analisando quais recursos foram retornados dessa requisição. É exatamente nesse ponto mencionado que focaremos a partir de agora, para explicar sobre os recursos. No HTTP, muito do que é retornado é, na verdade, um recurso. No caso da requisição do navegador a uma página, estamos obtendo o recurso visual da página solicitada. Para que adentremos ainda mais no conceito e criemos nossos futuros serviços REST, a partir desta leitura considere chamar URLs de URIs (Unified Resource Identifier), que basicamente consiste em ser o identificador único de um recurso. As URIs, no final das contas, constituem uma cadeia de caracteres compacta usada para identificar um recurso de internet. Para fixar ainda mais o conceito do que é um recurso, vamos utilizar o seguinte exemplo: Imagine que você esteja sem gasolina em uma cidade que não conhece. Assim, para em um local e, ao perguntar para alguém onde fica o posto mais próximo, essa pessoa comenta que o posto mais próximo fica a 5 km de distância. Até o momento, você deseja apenas encontrar esse tal posto o mais rápido possível, pois está quase sem combustível. Em seu caminho até o posto, talvez surja em sua mente a seguinte questão: Legal, mas qual é o nome do posto de gasolina e será que eles possuem álcool além de gasolina? Partindo desse exemplo fictício, saiba que suas futuras APIs cairão no mesmo questionamento: Como será identificado um recurso a se utilizar e o que ele oferece para consumo de dados? Ou seja, quando você optar por criar as URIs, leve
38
Aprendendo Laravel
em conta que elas representam os futuros recursos do seu serviço. Desse modo, nunca devem ser criadas com nomes que não condizem com o recurso retornado. Por exemplo, poderíamos criar uma URI para o nosso exemplo fictício do posto de gasolina que seria identificado da seguinte maneira: /posto-de-qualquer/gasolina. Mesmo no mundo real essa identificação é um tanto quanto confusa, pois não sabemos se podemos abastecer o carro com gasolina normal ou aditivada, e, inclusive, se poderíamos abastecer com álcool etc. O que ocorre em nosso exemplo é que um recurso não ajuda a identificar uma operação que pode ser utilizada. Ou seja, não está especificada uma boa identificação do recursos e também não existe uma separação lógica de cada operação que esse serviço pode realizar. Imagine mentalmente que poderíamos ajustar essa confusão apenas deixando o serviço com uma boa identificação e também com uma separação de responsabilidade: • Posto-de-gasolina • Inserir a gasolina • Obter a gasolina • Atualizar total de gasolina na bomba • Excluir litros de gasolina na bomba No nosso serviço REST, a operação de inserção de gasolina deve estar no método POST, que indica a criação/adição de gasolina. Em consequência, teríamos os outros verbos que fariam com que sua API obtivesse uma separação lógica para inserção de gasolina, obtenção de gasolina etc. É possível perceber que a construção de um Webservices REST segue bem a separação de recursos, boa identificação e operações. Isso faz com que seu usuário consiga facilmente consumir o seu serviço, pois, com uma bom identificação e uma separação de recursos e documentação, qualquer um poderá consumir.
1.5.4 Operações Agora que você já sabe o que pode oferecer, aprenderemos que esses nossos recursos vão ofertar operações diferenciadas e precisam ser separados em operações que, em nossas futuras aplicações REST, separemos em um conjunto de operações bem definidas que cada recurso pode oferecer.
Capítulo 1 ■ Introdução
39
No caso da bomba de gasolina, você deve ter percebido que adicionar o combustível na bomba do posto é um recurso de adição do tipo POST. Perceba, porém, que essa não é a única operação que esse recurso pode oferecer. Poderíamos, sim, utilizar o recurso da gasolina, mas também poderíamos decidir por utilizar a operação de gasolina aditivada ou gasolina comum, ou seja, adicionar gasolina comum e aditivada são operações equivalentes, porém agem de forma diferenciada. Voltando um pouco no assunto do protocolo HTTP, você já aprendeu um pouco sobre a importância da separação das operações e seus verbos. Além disso, já sabemos que esses verbos precisam ser bem definidos e que para cada rotina um verbo se fará necessário. No total, você pode utilizar sete operações de separação de recursos; cada método pode possuir uma lógica semântica diferenciada de modo que, juntando-se a uma URI, nossas operações então representarão nossas futuras ações, o que em nosso exemplo do posto de gasolina resultaria nas seguintes operações: • GET – Verbo responsável por cuidar de todas as nossas recuperações de informações, ou seja, se preciso do total de gasolina do posto A, poderia então obter essa informação a partir do serviço: postodeservicos.com.br/totalgasolina/ posto/x. Depois de realizar a consulta desse recurso pela operação de recuperar o totaldegasolina, já saberíamos que no posto A o total de gasolina é X. Tenha em mente a seguinte regra: O verbo GET só é responsável por obtenção de informações do seu serviço e apenas isso que ele deve fazer, ou seja, um verbo GET não deveria conseguir realizar uma operação de inserção em seu sistema. • POST – Responsável por criar todas as nossas necessidades de criação de informação de recurso, ou seja, por inserir o total de gasolina solicitado ao frentista. Poderia ser representado da seguinte maneira: postodeservicos.com.br/inserirgasolina. Após essa chamada, será então realizada a inserção de recurso de gasolina e o total solicitado pelo cliente será inserido no tanque do carro com sucesso. • PUT – Verbo comumente utilizado para atualizações de recursos. Em nosso caso do posto de gasolina, poderia ser representado da seguinte maneira: postodeservicos/preco/gasolina. Basicamente consiste em um serviço que atualiza o preço cobrado de gasolina do posto. • DELETE – Representa uma ação de remoção de um serviço oferecido, ou seja, em nosso exemplo serve para remover um serviço oferecido no posto de gasolina. Imagine que o posto passe a não mais oferecer gasolina aditivada
40
Aprendendo Laravel
power, pois descobriram que esse tipo de combustível agride o motor dos carros. Você poderia, por exemplo, criar o seguinte serviço: postodeservicos/ gasolina/tipo/power e a partir dessa chamada já ter removido a possiblidade de seus clientes obterem a gasolina do tipo aditivada power. Para título de fixação do conteúdo, poderíamos anteriormente obter essa gasolina no serviço de obtenção de gasolina, ou seja, a partir do verbo GET da seguinte maneira: postodeservicos/gasolina/aditivada/power. • HEAD, OPTIONS e TRACE – Geralmente é utilizado para quando você necessita recuperar dados de metadados da URI que está gerando a chamada. Com o conhecimento adquirido com esse pequeno overview, criar suas APIs usando o Laravel será muito mais tranquilo futuramente. A ideia central de comentar sobre recursos, HTPP, API e Rest é passar uma introdução para que, quando fizermos uso do Laravel com essa tecnologia, fique claro o porquê de o Laravel utilizar no routes.php o GET, POST, PUT e DELETE para rotas até a controladora. Caso esteja preocupado por ainda não ter fixado muito bem os assuntos discutidos até agora, fique calmo, pois no decorrer da leitura muito do que vimos agora será mais bem diluído.
1.6 Namespaces Em nossa jornada nesse mundo Laravel, você poderá em um certo momento perceber e/ou notar que existe a utilização dos espaços de nomes (namespaces) no Laravel. Começar a usar sem conhecer o conceito é ruim, pois, mesmo sabendo que nosso foco é terminar o livro como verdadeiros Artesões Laravel, esses pequenos detalhes se fazem necessário, mesmo sendo um assunto mais da linguagem do que do próprio framework. Alguns desenvolvedores não conhecem o que são namespaces ou muitas vezes o utilizam sem saber muito bem o que eles solucionam. No entanto, acreditamos que, pelo seu tempo com o PHP, já tenha passado pelo problema de ter uma aplicação que possui uma estrutura do projeto muito grande e, ao realizar uma chamada de um script que possui uma classe, ter cometido o erro de dar nomes iguais para o mesmo objeto. Para ilustrar o problema, imagine que alguém da sua equipe tenha criado uma class com o nome Usuário e talvez você inicialmente não veja problema algum com o nome dessa class, correto? Agora pare e imagine qual a probabilidade de outro desenvolvedor utilizar esse mesmo nome.
Capítulo 1 ■ Introdução
41
Vamos reproduzir então o erro de nomes que ocorre quando você utiliza duas classes com o nome Usuario. Crie em seu servidor web os arquivos teste1.php e teste2.php. Veja os exemplos nas listagens 1.3 e 1.4.
Listagem 1.3 (teste1.php) – Script para exemplo de erro de nome <?php class Usuario { public function __construct() { return self::class; } }
A estrutura da segunda classe de usuário teste2.php pode ser vista na Listagem 1.4.
Listagem 1.4 (teste2.php) – Script para exemplo de erro de nome <?php class Usuario { public function __construct() { return self::class; } }
Crie também um arquivo chamado testarExemplos.php. Ele vai testar seus objetos. Ao criar o script, repare que, ao executar, será retornado um erro. Para que fosse possível visualizar o erro, foram implementadas duas configurações que farão com que o PHP exiba os erros gerados que são: ini_set e error_reporting. Veja a seguir na Listagem 1.5.
Listagem 1.5 (testarExemplos.php) – Script para teste dos objetos de usuario <?php ini_set('display_errors', true); error_reporting(E_ALL); require_once 'teste1.php'; require_once 'teste2.php'; $u1 = new usuario(); $u2 = new usuario(); echo "<pre> Exemplos: "; var_dump($u1); echo "<br />"; var_dump($u2);
42
Aprendendo Laravel
O erro mencionado na execução do teste ocorre pelo fato de não possuirmos distinção entre os nomes de classe, ou seja, ao instanciar o objeto de usuário, o interpretador do PHP verifica que existem duas classes para o mesmo objeto e então dispara um erro. Esse problema já é bem antigo, mas, caso você ainda não o conheça, podemos citar então alguns exemplos de bibliotecas que tentavam solucionar isso sem os namespaces. Essas bibliotecas que em grande parte eram grandes ou eram grandes projetos tentavam solucionar esse problema com um padrão de prefixo de método, classe ou função. Você também poderia perceber os erros com essas bibliotecas, mas isso não acontecia porque elas utilizavam a regra do prefixo ou nomes longos para declaração de suas classes como WordPress, que tem o prefixo padrão wp_. Outro exemplo que podemos citar é o do Zend Framework 1, no qual você conseguia encontrar o prefixo padrão Zend_. Um exemplo de classe pode citar a Http que continha o padrão de prefixo de nome: Zend_Amf_Request_Http. Caso tenha curiosidade de conhecer um pouco mais da classe comentada, veja a sua estrutura no link https://github.com/zendframework/zf1/blob/master/library/Zend/Amf/Request/Http.php. Agora, saindo um pouco das bibliotecas e indo para o nosso dia a dia, imagine que você não possui a regra de prefixo em seu sistema e, com isso, encontrou duas classes com o mesmo nome, ou, pior ainda, imagine que você baixou uma biblioteca de terceiro onde exista uma classe usuário. Talvez esteja pensando: Ah, isso é fácil solucionar, basta buscar onde está essa classe e então alterar esse nome. No entanto, essa tarefa pode se tornar uma verdadeira dor de cabeça, mas ajustar esse problema em uma classe é fácil; agora imagine esse mesmo problema em várias classes! Felizmente existem os namespaces, uma solução fácil para esse problema. A partir da versão PHP 5.3, você já consegue utilizar esse recurso e o que faremos agora é ajustar nossos exemplos para conseguir utilizar nomes de classes iguais. A alteração que faremos no arquivo teste1.php não é grande. Repare na utilização da palavra namespace. Veja a seguir na Listagem 1.6.
Listagem 1.6 (teste1.php) – Script com a alteração para namespace <?php namespace teste1; class Usuario {
Capítulo 1 ■ Introdução
43
public function __construct() { return self::class; } }
Quando inserimos a instrução namespace para o script teste1.php, conseguimos então de forma simples ajustar o problema. No entanto, para ajudar a esclarecer ainda mais o que são os namespaces, imagine que ao inserir o namespace você analogicamente esteja falando em criar uma pasta em seu sistema operacional e que a classe Usuario seja na verdade um arquivo que será colocado nessa pasta que, em nosso caso, são os namespaces. Pensando dessa forma, até em um sistema operacional existe o caso de não poder ter nomes iguais de arquivos no mesmo espaço, por exemplo, você não consegue em seu sistema ter dois arquivos de usuario.txt na mesma pasta. Isso se reflete também no mundo da programação, onde um arquivo ou uma classe não podem coexistir com os mesmos nomes. Agora talvez tenha passado pela sua cabeça que isso é fácil de resolver e que você não precisará desse tal de namespace e que, na verdade, o que você precisa fazer é mais simples. Basta deixar um arquivo com um nome diferente do outro em sua pasta que tudo vai funcionar. Talvez, porém, o que você não tenha visto é que em nosso exemplo os nomes de pasta são diferentes, correto? Sendo assim, o que realmente conta para o interpretador do PHP é o nome da sua classe, e não do script que o compõe. Talvez você ainda pense em outra possibilidade, que seria a de colocar o nome da classe Usuario com o início de nome em minúsculo, ou seja, se eu trocar Usuario para usuario terei solucionado o problema. No entanto, já adianto a você que nem perca seu tempo, pois colocar Usuario em minúscula vai gerar o mesmo erro, uma vez que o PHP entende que Usuario e usuario são as mesmas coisas e não podem coexistir. Partindo então de tudo o que acabamos de aprender, esse mesmo problema se reflete a você não poder utilizar namespaces iguais, pois, como utilizado no exemplo do sistema operacional, não é possível ter duas pastas com o mesmo nome, correto? Sendo assim, vamos então ajustar o script teste2.php que ficará muito parecido com o teste1.php. O que muda é que o namespace que utilizaremos é o teste2. Desse modo, fica com o namespace diferente da primeira classe. Veja a seguir na Listagem 1.7.
44
Aprendendo Laravel
Listagem 1.7 (teste2.php) – Script com a alteração para namespace <?php namespace teste2; class Usuario { public function __construct() { return self::class; } }
Repare que nosso arquivo de teste sofre também algumas alterações, que basicamente consistem em informar que vamos utilizar os espaços reservados de nomes que criamos a partir da instrução use. O PHP é capaz de utilizar os espaços com a instrução use, pois nós criamos os namespaces nos scripts teste1.php e teste2.php. Veja o exemplo na Listagem 1.8.
Listagem 1.8 (testarExemplos.php) – Script para teste do usuário <?php ini_set('display_errors', true); error_reporting(E_ALL); require_once 'teste1.php'; require_once 'teste2.php'; //Primeira forma use teste1\Usuario as usu1; use teste2\Usuario as usu2; $u1 = new usu1(); $u2 = new usu2(); echo "<pre> Exemplos: "; var_dump($u1); echo "<br />"; var_dump($u2);
Como foi comentado, fez-se necessária a utilização da palavra use que permite utilizar um espaço de nome (namespace), porém repare que também foi necessário utilizar uma aliases (as) na chamada da classe. Nós a utilizamos em nossa chamada do espaço de nomes, pois queríamos informar à instrução que realizaríamos a instrução de renomear a chamada do nosso espaço de nome. Isso foi necessário, pois, por mais que tivéssemos os nomes de espaço, o PHP não seria capaz de identificar qual classe Usuario estamos querendo utilizar.
Capítulo 1 ■ Introdução
45
O erro que poderia ser gerado na chamada caso não existisse a aliases é o seguinte: [Sun Dec 06 16:17:07 2015] [error] [client ::1] PHP Fatal error: Cannot use teste2\\Usuario as Usuario because the name is already in use in /var/www/teste/ index.php on line 11, referer: http://localhost/
Existe outra forma de utilizarmos as nossas classes de Usuario sem que haja a necessidade de renomear para um novo nome. É o que precisamos ao utilizar o use e darmos a chamada diretamente para seu espaço de nome via instância do objeto, como pode ser visto na Listagem 1.9:
Listagem 1.9 (testarExemplos.php) – Script para teste do usuário <?php ini_set('display_errors', true); error_reporting(E_ALL); require_once 'teste1.php'; require_once 'teste2.php'; //Segunda forma use teste1; use teste2; $u1 = new teste1\Usuario(); $u2 = new teste2\Usuario(); echo "<pre> Exemplos: "; var_dump($u1); echo "<br />"; var_dump($u2);
A terceira forma de chamar nossas classes seria encadear as chamadas separando-as por , (vírgula) em um único use. Veja a seguir na Listagem 1.10:
Listagem 1.10 (testarExemplos.php) – Script para teste do usuário <?php ini_set('display_errors', true); error_reporting(E_ALL); require_once 'teste1.php'; require_once 'teste2.php'; //Terceira forma use teste1, teste2; $u1 = new teste1\Usuario(); $u2 = new teste2\Usuario();
46
Aprendendo Laravel echo "<pre> Exemplos: "; var_dump($u1); echo "<br />"; var_dump($u2);
Como você deve ter percebido, os espaços de nomes são importantes para o nosso sistema. Além disso, também ajudam em relação a mantermos um melhor controle da nossa aplicação, pois permitem que você crie um padrão a ser utilizado e que o nome do espaço seja equivalente à pasta que mantém o script. Em nosso exemplo, os arquivos de teste deveriam pertencer às pastas teste1 e teste2; caso em seu projeto seja necessário criar subpastas, você poderá seguir o seguinte padrão: teste1\sub-pasta\usuario.php ou teste2\sub-pasta\usuario.php.
1.7 Notação de objetos Javascript (JSON) Antes de falarmos sobre JSON, é importante salientar para você, futuro Artesão Laravel, o quão essencial ele é. Na maioria dos casos, o controle que você tem sobre sua estrutura será em muitas vezes mantido por arquivos .json; por exemplo, o arquivo de controle de dependências do seu projeto Laravel é o composer.json. Até mesmo para o que aprendemos anteriormente, criar um webservice utilizando REST, preferencialmente você poderá acabar decidindo por utilizar um JSON como resposta a uma requisição do consumidor/usuário. Podemos citar como exemplo de API a do Facebook ou Twitter. Você pode acabar chegando à conclusão de que eles tendem a querer responder suas requisições com formato JSON por padrão, por esse motivo, você, desenvolvedor Laravel, precisa se aprofundar um pouco mais nesse padrão. O Padrão JSON serve para manter sua estrutura, consumir API, entre outros. É essencial você entender por que muitos escolhem o JSON como padrão ideal para controle de sua estrutura e resposta a requisições. Nosso objetivo como desenvolvedor Laravel/Artesão é entender pelo menos o básico de JSON. JSON (JavaScript Object Notation – Notação de objetos JavaScript) não é uma string qualquer e sem sentido.O JSON nasceu com o intuito de ser uma formatação leve para troca de dados entre sistemas. Para você, desenvolvedor PHP/Laravel, utilizamos o JSON para além do controle da estrutura para respostas dos nossos serviços, e isso ocorre porque o padrão JSON é muito fácil de criar e parsear isso
Capítulo 1 ■ Introdução
47
ocorre pelo fato de sua conspecção ter sido pensada para ser mais bem entendida por seres humanos, ou seja, o JSON é um padrão bem mais simples de ser não apenas lido, mas também escrito, diferente do padrão de troca de informações entre sistemas que antes era em XML sob o protocolo SOAP que tendia a ser bem mais complexo. Uma questão interessante que podemos levar em consideração na escolha do JSON para o Composer e tantas outras tecnologias que utilizam o formato JSON é a conspecção principal que o JSON prega, a qual é: Ser leve para ser mantido em seu projeto, ser facilmente lido e criado. O JSON é um formato de texto que fica independentemente das linguagens de programação que você estiver utilizando, as quais em nosso caso serão: PHP e JavaScript. A partir do Capítulo 2, vamos focar mais no Laravel e mais à frente um pouco no JavaScript.
1.8 Conclusão Este capítulo de introdução ajudou você a se habituar com as tecnologias que serão utilizadas no Laravel. A ideia central é ajudar quem ainda não estava muito habitado com as tecnologias: REST, JSON, XML, Namespaces e Composer. Caso queira saber um pouco mais sobre as tecnologias mencionadas, leia a documentação delas e se aprofunde na gama de assuntos que possuem. Segue uma lista interessante de links que podem ajudá-lo: • http://www.json.org/ • https://tableless.com.br/composer-para-iniciantes/ • https://www.w3schools.com/xml/ • http://www.restapitutorial.com/