ensino tÉcnico notas de aulas ds ii 1 - marcoscosta.eti.br de aulas dsii.pdf · documentação...

ENSINO TÉCNICO Notas de aulas – DS II 1

DS II Profº Marcos Costa de Sousa DE

.Competências, Habilidades e Bases Tecnológicas da disciplina de Desenvolvimento de Software II



1-) Comunicação de alunos com alunos e professores:

Um e-mail para a sala é de grande valia para divulgação de material, notícias e etc.

Criação de grupo nas redes sociais também é interessante. 2-) Uso de celulares:

Para o bom andamento das aulas, recomendo que utilizem os celulares em vibracall, para não atrapalhar o andamento da aula. 3-) Material das aulas:

A disciplina trabalha com NOTAS DE AULA que são disponibilizadas ao final de cada aula, e calendários de PTCC estarão disponíveis no site: www.marcoscosta.eti.br, na página principal. 4-) E-mail da disciplina:

A disciplina terá um e-mail de envio das atividades, dúvidas e assim por diante, assim sendo todas as atividades deverão ser enviadas para tal e-mail, se forem enviadas atividades de tal disciplina para e-mail não mencionado, a atividade será desconsiderada.

O e-mail desta disciplina é: [email protected] 5-) Prazos de trabalhos e atividades:

Toda atividade solicitada terá uma data limite de entrega, de forma alguma tal data será postergada, ou seja, se não for entregue até a data limite a mesma receberá menção I, isso tanto para atividades entregues de forma impressa ou enviadas ao e-mail da disciplina. No caso de DTCC o calendário será seguido, e no dia marcado de determinada atividade só receberão menção os alunos presentes, caso não estejam, a menção para aquela atividade será I. 6-) Qualidade do material de atividades:

Impressas ou manuscritas: Muita atenção na qualidade do que será entregue, atividades sem grampear, faltando nome e número de componentes, rasgadas, amassadas, com rebarba de folha de caderno e etc. serão desconsiderados por mim.

Digitais: Ao enviarem atividades para o e-mail da disciplina, SEMPRE no assunto deverá ter o nome da atividade que está sendo enviada, e no corpo do e-mail deverá ter o(s) nome(s) do(s) integrante(s) da atividade, sem estar desta forma a atividade será DESCONSIDERADA.

7-) Menções e critérios de avaliação:

Na ETEC os senhores serão avaliados por MENÇÃO, onde temos: - MB - Muito Bom;

- B - Bom; - R - Regular; - I - Insatisfatório.

1. Introdução

O CodeIgniter (ou CI, como muitos chamam, e nós também) é um framework MVC open source, escrito em PHP e mantido atualmente pelo British Columbia Institute of Technology e por uma grande comunidade de desenvolvedores ao redor do mundo. Sua simplicidade faz dele um dos mais utilizados e com uma curva de aprendizado bem pequena.

Sua documentação é bem completa e detalhada, facilitando o processo de pesquisa sobre determinada biblioteca ou funcionalidade. Com isso, o tempo gasto com a leitura da documentação diminui, e você pode passar mais tempo trabalhando no código do seu projeto. Com o CI, é possível desenvolver sites, APIs e sistemas das mais diversas complexidades, tudo de forma otimizada, organizada e rápida. Suas bibliotecas nativas facilitam ainda mais o processo de desenvolvimento, e ainda permitem ser estendidas para que o funcionamento se adapte à necessidade de cada projeto. Diversas bibliotecas de terceiros ( third-party ) estão



disponíveis no GitHub, Composer e em outros repositórios de arquivos, e podem ser muito úteis.

Mais detalhes sobre o CI podem ser vistos no site do framework (https://codeigniter.com) e em sua documentação (https://codeigniter.com/user_guide). 2. Requisitos mínimos

Para um melhor aproveitamento, é recomendado o uso de PHP 5.4 ou mais recente. Ele até funciona com PHP 5.2, mas é recomendado que você não utilize versões antigas do PHP, por questões de segurança e desempenho potenciais, bem como recursos ausentes.

Algumas aplicações fazem uso de banco de dados, e o CodeIgniter suporta atualmente:

MySQL(5.1+), mysqli e PDO drivers

Oracle (drivers oci8 e PDO)

PostgreSQL (postgre a PDO)

MSSQL (mssql, sqlsrv e PDO)

Interbase/Firebird (ibase e PDO)

ODBC (odbc e PDO) O CI pode ser instalado em sistemas operacionais UNIX (Linux e Mac OS X) e

Windows, desde que o ambiente de desenvolvimento com Apache ou Nginx (UNIX) e IIS (Windows) estejam devidamente montados e funcionando.

3. Instalando o CodeIgniter

O processo de instalação do CI é muito simples e fácil de ser executado. O primeiro passo é fazer o download do framework. Para isso, você tem duas possibilidades: Clique em Download na home, conforme mostrado na figura:

Acesse o repositório do projeto no GitHub (https://github.com/bcit-ci/CodeIgniter) e faça o download clicando em Download ZIP, conforme a figura a seguir:

https://codeigniter.com/user_guide



Após fazer o download, descompacte o arquivo no diretório onde codificará o projeto, chamando esse diretório de instalacao-ci. Mantenha o arquivo ZIP que você baixou em algum local na sua máquina, e assim não há a necessidade de um novo download.

DIRETÓRIO EXCLUSIVO PARA OS EXEMPLOS DAS NOTAS DE AULA Crie um diretório exclusivo para os exemplos de nossa aula, pode chamá-lo de CI01, vou disponibilizar para vocês. Assim, fica tudo organizado e fácil de você localizar os códigos conforme forem sendo referenciados nas aulas.

Feito isso, sua estrutura de arquivo no diretório instalacaoci deve ser como a mostrada

a seguir:

Dos arquivos e diretórios da estrutura, você pode remover o diretório user_guide, pois

ele contém apenas a documentação do CI, e os arquivos contributing.md e readme.rst , que trazem informações sobre como contribuir com o desenvolvimento do CI e informações sobre eles, respectivamente.



Feito isso, você pode testar a instalação acessando a URL correspondente ao diretório no seu servidor local. Essa URL pode variar, mas levando em consideração que você esteja utilizando localhost e nomeou os diretórios conforme orientado anteriormente, ela seria a

seguinte: http://localhost/instalacao-ci/ci01 E o resultado deverá ser:

Pronto, você já instalou o CI e agora é hora de conhecer um pouco mais sobre a estrutura de arquivos e diretórios dele.

4. Estrutura de arquivos e diretórios do Codeigniter

Agora que o CodeIgniter já está instalado e funcionando, mostrarei com mais detalhes

a estrutura de arquivos e diretórios. É importante conhecê-la para que possa organizar o seu código da melhor maneira possível, e fazer o uso correto dos recursos que o CI disponibiliza.

Diretório application Esse é o diretório da aplicação, onde ficarão todos os arquivos relacionados ao projeto. Ele é composto de 12 diretórios, que farão com que os arquivos do projeto fiquem bem

divididos e separados dos arquivos do "core" do CI. Assim, você poderá atualizar a versão do CI sem ter de mudar os arquivos do projeto de diretório ou estrutura.

cache ─ Diretório que armazena os arquivos que são colocados em cache.

config ─ Diretório que armazena os arquivos de configuração do CI, como por exemplo, database.php , constants.php , routes.php , entre outros que veremos no decorrer das aulas.

controllers ─ Diretório que armazena os arquivos com os controllers do projeto. Ao instalar o CI, ele já vem com um controller criado, que é o Welcome.php .

core ─ Diretório usado para estender classes e funcionalidades do core do CI, adaptando-se às necessidades do projeto.

helpers ─ Diretório que armazena os arquivos com funções que funcionarão como assistentes durante o desenvolvimento. Por exemplo, você pode criar um helper (assistente) para determinado grupo de tarefas realizadas com frequência dentro do projeto, ou então estender as funcionalidades dos helpers nativos do CI.

hooks ─ Diretório que armazena os arquivos que também estendem funcionalidades padrão do CI. Você pode criar um hook para alterar uma funcionalidade padrão, como por exemplo, minificar o código HTML de saída quando o método load->view() for executado.

language ─ Diretório que armazena os arquivos com os dicionários de idiomas, assim você pode desenvolver projetos multi-idiomas de forma fácil, e também utilizar os outros idiomas dos pacotes de tradução oficiais do CI, que podem ser encontrados em https://github.com/bcit-ci/codeigniter3-translations.

libraries ─ Diretório que armazena as libraries (bibliotecas) criadas para o projeto, ou libraries estendidas do core do CI.

logs ─ Diretório que armazena os arquivos de log, que são configurados em application/config/config.php.

http://localhost/instalacao-ci/ci01



models ─ Diretório que armazena os arquivos onde ficarão as regras de negócio do projeto.

third_party ─ Diretório que armazena código de terceiros, como classes que podem auxiliar em alguma rotina do projeto e que foram desenvolvidas por outros programadores e/ou não possuem os padrões do CI.

views ─ Diretório que armazena arquivos que serão carregados no browser. Você pode inserir outros diretórios dentro dele para organizar os arquivos da melhor maneira possível.

Nem sempre você fará uso de todos os diretórios dentro de application , os mais

utilizados são: controllers, libraries, logs, models e views. Mas o uso fica a critério do desenvolvedor e da necessidade do projeto.

Diretório system Esse diretório armazena o core do CI, e o conteúdo dos arquivos contidos nesse

diretório não devem ser alterados. Isso porque, para manter o CodeIgniter atualizado, na maioria das versões basta substituir o conteúdo desse diretório pelo conteúdo do mesmo diretório na versão mais recente.

Ele possui apenas seis outros diretórios, muito bem divididos, e com os arquivos nomeados de forma bem intuitiva. Assim, caso queira estudar mais a fundo o funcionamento do CI, você pode fazê-lo analisando o código-fonte dos arquivos desse diretório.

Arquivos index.php e composer.json O arquivo index.php é o arquivo base de um projeto feito com CI. Ele carrega o arquivo

de core necessário para a carga das libraries, helpers, classes, entre outros arquivos do framework e execução do código escrito por você.

Nesse arquivo, você pode alterar a localização dos diretórios system e application, configurar as exibições de erro para os ambientes do projeto (desenvolvimento, teste e produção, por exemplo), customizar valores de configurações, entre outras possibilidades. Quase não se faz alteração nesse arquivo, mas durante as aulas serão feitas algumas, para que possam atender aos requisitos dos exemplos.

O arquivo composer.json se tornou parte integrante do CI a partir da versão 3, quando foi adicionado o suporte nativo ao Composer (https://getcomposer.org/). É nesse arquivo que são adicionadas as configurações de dependências do projeto, para que as bibliotecas sejam instaladas automaticamente a partir da execução de uma linha de comando.

5. Padrão MVC

MVC é o acrônimo de Model-View-Controller (em português, Modelo-Visão-Controle) e

que, como o próprio nome supõe, separa as camadas de uma aplicação em diferentes níveis. Ao contrário do que muitos desenvolvedores dizem, o MVC não é um Padrão de Projeto, mas sim um Padrão de Arquitetura de Software.

O MVC define a divisão de uma aplicação em três componentes: Modelo, Visão e Controle. Cada um destes componentes tem uma função específica e estão conectados entre si. O objetivo é separar a arquitetura do software para facilitar a compreensão e a manutenção.

A camada de Visão é relacionada ao visual da aplicação, ou seja, as telas que serão exibidas para o usuário. Nessa camada apenas os recursos visuais devem ser implementados, como janelas, botões e mensagens. Já a camada de Controle atua como intermediária entre as regras de negócio (camada Modelo) e a Visão, realizando o processamento de dados informados pelo usuário e repassando-os para as outras camadas. E por fim, temos a camada de Modelo, que consiste na essência das regras de negócio, envolvendo as classes do sistema e o acesso aos dados. Observe que cada camada tem uma tarefa distinta dentro do software.



Explicação do conceito do MVC Certo, mas qual é a vantagem?

A princípio, pode-se dizer que o sistema fica mais organizado quando está estruturado

com MVC. Um novo desenvolvedor que começar a trabalhar no projeto não terá grandes dificuldades em compreender a estrutura do código. Além disso, as exceções são mais fáceis de serem identificadas e tratadas. Ao invés de revirar o código atrás do erro, o MVC pode indicar em qual camada o erro ocorre. Outro ponto importante do MVC é a segurança da transição de dados. Através da camada de Controle, é possível evitar que qualquer dado inconsistente chegue à camada de Modelo para persistir no banco de dados. Imagine a camada de Controle como uma espécie de Firewall: o usuário entra com os dados e a camada de Controle se responsabiliza por bloquear os dados que venham a causar inconsistências no banco de dados. Portanto, é correto afirmar que essa camada é muito importante.

Posso ter apenas três camadas no MVC?

Eis que essa é outra dúvida bastante questionada pelos desenvolvedores. Embora o MVC sugira a organização do sistema em três camadas, nada impede que você “estenda” essas camadas para expandir a dimensão do projeto. Por exemplo, vamos supor que um determinado projeto tenha um módulo web para consulta de dados. Aonde esse módulo se encaixaria dentro das três camadas?

Bem, este módulo poderia ser agrupado com os outros objetos da camada Visão, mas seria bem mais conveniente criar uma camada exclusiva (como “Web”) estendida da camada de Visão e agrupar todos os itens relacionados a esse módulo dentro dela. O mesmo funcionaria para um módulo Mobile ou WebService. Neste caso, a nível de abstração, essas novas camadas estariam dentro da camada de Visão, mas são unidades estendidas.

Mas o acesso ao banco de dados não é uma função da camada de Modelo? Sim, é. Inclusive muitos profissionais preferem denominar a classe de Modelo

como Business Object Model, responsável pela modelagem e acesso ao banco de dados ao mesmo tempo. Mas essa é uma premissa particular de cada desenvolvedor. No meu caso, achei conveniente manter as classes do projeto (modelagem) e o acesso ao banco de dados em camadas diferentes. Sendo assim, criei uma camada estendida da camada de Modelo para o acesso ao banco de dados, conhecida como DAO (Data Access Object) ou DAL (Data Access Layer). É uma camada bem simples, apenas com os objetos de conexão com o banco de dados e as instruções SQL, mas que proporcionou uma melhor organização no meu código. Mas lembre-se: um projeto com várias camadas torna-se tão confuso quanto um projeto de uma camada só. Separe a implementação quando notar que a mesma camada está realizando duas ou mais tarefas diferentes, e que dividindo-as tornará o projeto mais compreensível. Então podemos concluir resumidamente

MVC é nada mais que um padrão de arquitetura de software, separando sua aplicação em 3 camadas. A camada de interação do usuário(view), a camada de manipulação dos dados(model) e a camada de controle(controller).

Model quando você pensar em manipulação de dados, pense em model. Ele é responsável pela leitura e escrita de dados, e também de suas validações.

View é a camada de interação com o usuário. Ela apenas faz a exibição dos dados.



Controller é o responsável por receber todas as requisições do usuário. Seus métodos chamados actions são responsáveis por uma página, controlando qual model usar e qual view será mostrado ao usuário.

(A imagem abaixo representa o fluxo do MVC em um contexto de Internet, com uma requisição HTTP e resposta em formato HTML ou XML)

O diálogo das camadas na Web (Brincadeirinha)

View - Fala Controller! O usuário acabou de pedir para acessar o Facebook! Pega os dados de login dele ai.

Controller – Blz. Já te mando a resposta. Ai model, meu parceiro, toma esses dados de login e verifica se ele loga.

Model – Os dados são válidos. Mandando a resposta de login.

Controller – Blz. View, o usuário informou os dados corretos. Vou mandar pra vc os dados dele e você carrega a página de perfil.

View – Vlw. Mostrando ao usuário… Atividade avaliativa. Em grupo, criem uma apresentação conceituando o padrão MVC em CodeIgniter, teremos um seminário no dia 09 de Agosto de 2018. 6. Mãos a obra Em nossas aulas utilizaremos a práxis (prática) para aprendermos a utilizar o php com codeigniter, então a ideia é montarmos um sistema de compras que terá a seguinte decomposição funcional:



A cada aula nosso objetivo é montarmos a estrutura de cada módulo da ideia acima, portanto a frequência nas aulas é de suma importância para o bom andamento das mesmas. 6.1. Parâmetros iniciais no Codeigniter Antes de efetivamente programarmos nosso sistema, devemos configurar os arquivos na pasta config do nosso sistema: Routes -> mudando o default_controller de acordo com nossa controller específica do projeto, nesse caso estamos chamando a controller de login:

Config -> mudar a base_url, para a base do seu projeto por exemplo: “http://localhost/compras/” :

Autoload -> acrescentar no array da helper “url”:

Login

Cadastro

Produtos

Usuários

Consultas

Pedido de compras

Solicitações

Realizar pedidos

Administrar pedido



E libraries também com database e session:

Htaccess -> O CodeIgniter por padrão já dá suporte a URL amigáveis, como os grandes frameworks em PHP, o grande problema é que ele ainda insiste em mostrar o arquivo index.php na URL o que deixa toda requisição horrível. Veja o padrão de URL na instalação padrão do CodeIgniter: http://seusite.com.br/index.php/controller/method/parameter

Como deveria ser: http://seusite.com.br/controller/method/parameter Este problema é muito simples de resolver, basta configurar o servidor para trabalhar

com uma sobrescrita de URL, siga o passo-a-passo a baixo: Primeiro abra o arquivo config.php dentro da pasta \application\config e substitua as

linhas abaixo: $config[“index_page”] = “index.php”; para **$config[“index_page”] = “;

$config[“uri_protocol”] = “AUTO”; para $config[“uri_protocol”] = “REQUEST_URI”;



Como estamos usando o Apache como nosso servidor web, criamos um arquivo .htaccess com o seguinte conteúdo:

6.2 Montando o banco de dados Sempre disse em nossas aulas que a primeira ação que devemos realizar na confecção de um novo projeto de sistemas é a construção do banco de dados, para termos a base de implementação do sistema, mas como estamos abordando um conteúdo em aprendizado, iremos construir esse banco de dados por partes para facilitar o entendimento de vocês. 6.2.1 Tabela de login O primeiro passo é criarmos o login de nosso sistema, assim iremos contruir um banco de dados MySql com uma tabela que armazene essas informações, abaixo temos a estrutura da mesma:



Ao fazer a select o resultado aparecerá assim:

Após isso, temos que configurar o banco de dados no arquivo databases.php na pasta application/config, da seguinte forma:

6.3 Tela de Login Como diria o grande filósofo, “Vamos começar do começo”. A primeira tela que iremos construir em Codeigniter será um Login ao nosso sistema, a minha preocupação em nossas aulas como sempre disse, não será o front end e sim o back end, portanto montarei as telas de forma simples, ficando a critério, incrementar algo mais. Terei passado a vocês a pasta base do projeto que iremos trabalhar com essas configurações citadas acima, inclusive com os arquivos footer e header dentro da pasta view/includes, nessas teremos os arquivos necessários para rodar o Bootstrap 3, que estarão na pasta compras/assets que em nossas aulas exploraremos melhor. 6.3.1 Estrutura da tela de login Conforme citamos acima, nossa tela de login será composta por header, v_login e footer, em todas as telas de nosso projeto, trabalharemos dessa maneira, de forma simbólica a estrutura ficaria assim:

Na definição do Codeigniter e que vimos anteriormente, na Controller, no método index da classe Login, fazemos o carregamento da header, v_login e footer, devemos lembrar que em um projeto desse framework, o mesmo começa por uma controller. Veja:



Dessa forma a controller estará apta a chamar a header, v_login e footer, lembrando que o carregamento do bootstrap estão nesses dois arquivos (header e footer), abaixo coloco os dois arquivos: Header:



Footer:

6.3.2 Tela v_login.php Nessa tela faremos a montagem do layout da tela que ao final deverá ficar assim:

Esse layout já segue a ideia do bootstrap 3, como disse o foco do curso não é esse, mas vocês poderão explorar mais esse incrível mundo de layouts e facilidades. Inicialmente o arquivo v_login.php será formado:



Ao terminarmos de montar esse arquivo chamarmos a url do navegador, aparecerá:

O layout está pronto, agora vamos trabalhar a validação do usuário e a senha, para isso vamos utilizar o JavaScript, que é uma linguagem que monitora o comportamento das páginas onde a mesma é utilizada, e com o Ajax (JavaScript e XML Assíncronos) que são técnicas de programação que são utilizadas para carregar informações na página sem precisar recarregá-las. Abaixo temos o complemento da v_login utilizando JavaScript com Ajax, vejam:



6.3.3 Controller Login Agora vamos implementar nossa controller para que a mesma possa receber os atributos da View e solicitar que a Model faça a consulta no banco de dados e retorne se o usuário e a senha estão cadastrados no sistema, vejam:

6.3.4 Model m_acesso Para completar essa ponte, os atributos vindo da controller são passados na Query do banco de dados e retornam se os mesmos contam cadastrados. Vejam:



Com isso fechamos o ciclo View – Controller – Model (requisição) e o passo inverso com retorno da validação até a View. Com isso o JavaScript analisa o retorno e informa ao usuário na View se o login está correto ou não através da função Swal do Bootstrap. Vejam: Dados inválidos

Dados válidos

Assim finalizamos o login do sistema, na próxima etapa iremos confeccionar o menu com os acessos do sistema e trabalharmos com variáveis de sessão no PHP. 6.4 Sessões no PHP

Iremos agora saber um pouco mais e como aplicar variáveis de sessão no PHP. A sessão web é bem parecida com a sessão de um PC, que ao iniciar, temos que colocar usuário e senha, assim seu computador pode saber quem está usando a máquina e guardar os registros com segurança. Em um site ou sistema web, a sessão é importante quando se quer mais segurança na página ou quando se quer ter um controle de usuário. Também alguns programadores utilizam-se deste recurso para guardar informações e também se pode montar um carrinho de compra de um site de vendas, pois assim vão armazenando-se os itens ou produtos e só no final é que os dados são jogados no banco de dados.

Observação: ”A variável de sessão PHP é usada para armazenar informações sobre, ou alterar as configurações do sistema ou site para uma sessão de usuário. As variáveis de sessão armazenam informações sobre um único usuário e estão disponíveis para todas as páginas em um único aplicativo”. 6.4.1 Atribuindo as variáveis de sessão ao nosso projeto Continuando com nossa práxis, iremos complementar a Controller Login, atribuindo a variável de sessão que trata do usuário logado, logicamente que teremos que realizar uma validação para que preenchamos essa variável ou a destruíamos caso o usuário autenticado seja inválido, observem no código seguinte que teremos que alterar a Controller Login, no método logar_ajax:



Acima vocês observam que fazemos um tratamento com um IF, se retorno da model nos trouxer 1, iremos acrescentar o usuário a variável de sessão, caso contrário a destruímos. Dessa forma a variável de sessão já está criada e sendo atribuída caso o login esteja correto. 6.5 Menu

Com a validação correta, fazendo a atribuição do usuário a variável de sessão, agora iremos montar o menu de nosso sistema de compras.

Iremos agora ter que modificar a v_login, onde recebemos o resultado da Controller, iremos ao final onde informamos que o login está correto, substituiremos pelo caminho da Controller Home que carregará o menu para o sistema, vejam:



6.6 Classe Home Com a validação correta, e “setada” a variável de sessão, agora iremos montar o menu,

para isso no Controller home.php teremos a classe Home e o método índex, lembrando que ao chamarmos uma classe o método índex é instanciado, nesse método iremos carregar a Header, a Footer, o Menu, e a Body vejam:

6.7 Página Home Na página home, em nosso caso o Body, teremos um logo e texto para referenciar o sistema somente, vejam:

Na sequência faremos efetivamente o arquivo menu.php, que terá a decomposição

funcional abordada na primeira aula de acordo, como a seguir:



Essa parte HTML irei disponibilizar, agora abaixo desse código teremos o JavaScript que irá “linkar” as Controllers de cada página que iremos fazer, abaixo teremos a estrutura disso:



Ao final, o layout ficará assim:

6.8 Página Usuários Iremos fazer o primeiro cadastro de nosso sistema, iremos trabalhar com os usuários. A mesma terá um form pedindo o usuário e a senha, dois botões um para limpar e outro para



salvar, e um bootstrap table, mostrando os usuários já cadastrados. Mas antes de começarmos precisamos alterar o a função JavaScript usuários lá na menu.php, conforme abaixo:

Após isso vamos construir o controller usuario.php, lembrando que ao chamarmos a Controller na view, o Codiginiter irá procurar o método index da Classe, vejam:



Abaixo teremos o HTML da página de cadastro, vejam:



Ao final teremos esses resultado:

Teremos que criar dois métodos no JavaScript para que possamos fazer o evento de salvamento dos dados, e atualização da table com os dados dos usuários a cada 5 segundos, vejam na próxima página:



Dessa forma, nos que referimos ao front end está concluído agora iremos fazer o Controller que tratará o restante das coisas. 6.9 Controller Usuarios

Agora iremos fazer dois métodos dentro de nosso Controller, primeiramente o método listar() que será responsável pelos dados dos usuários para preenchimento da tabela, depois o método cadastrar() que será responsável pelo salvamento dos dados inseridos. Na próxima página observem os dois métodos:



Notemos que ambos os métodos instanciam o Model m_usuario, onde efetivamente a camada de banco de dados é consultada ou cadastrada. 6.10 Model m_usuario

Nesse model, teremos dois métodos, um que fará a consulta no banco de dados e retornará todos os usuários cadastrados e outro que fará a inclusão das informações na tabela de usuários do banco de dados, observem:



Assim finalizamos essa etapa da aula, testem e leiam o material de aula até fixarem tudo que abordamos hoje. 6.11 Incrementando nosso cadastro de usuários Vocês perceberam que até o momento fizemos algumas integrações entre View-Controller-Model, isso faz com que nos familiarizemos mais com esse novo conceito, agora vamos fazer a coluna de opções em nossa tabela que carrega os usuários cadastrados, iremos colocar dois botões, um para DESATIVAR e outra para ALTERAR os usuários. 6.11.1 Alterando a view v_usuario Para que consigamos realizar essa tarefa precisamos alterar essa view na parte onde trabalhamos com a tabela -> tableusu conforme abaixo mostro:



Agora programaremos no JavaScript a seguinte função:

Ela é responsável em criar dois botões como citei anteriormente com tipos do bootstrap, o que facilita muito o trabalho de front-end e atrelamos a cada botão a função JavaScript (busca_usuario() e desativa_usuario()) responsável por cada atividade. Ao final o front-end ficará assim:

6.11.2 Criando um Modal para alteração da senha do usuário Um conceito muito legal e interessante é do modal, onde ao clicarmos no ícone com um lápis, iremos abrir um Modal (Tela) para alteração da senha do usuário. O Código abaixo deverá ser inserido no final da view v_usuario.php, é um modal que será aberto ao clicar no ícone do lápis.



Criaremos agora a função JavaScript na v_usuario.php para buscar os dados do usuário, de acordo com o clique na tabela, vejam:

Já com isso podemos também criar o método consalterar na Controller usuario, vejam:



E também na Model m_usuario fazemos a consulta para acesso aos dados, vejam:

Ao final deverá aparecer assim:

Essa etapa realizada, damos oportunidade ao usuário de alterar somente a senha, o usuário fica bloqueado, em nosso caso entendo que caso queira alterar o usuário, o correto é desativá-lo e criar um novo, pois se o mesmo tiver feito algo no sistema perdemos a rastreabilidade. Para isso quando o usuário fizer a alteração da senha e clicar em “Alterar” deverá ser chamada a função JavaScript altera(), na v_usuario.php, vejam:



Agora faremos na Controller usuario o método alterar conforme abaixo:

E finalizando essa etapa acrescentamos no Model m_usuario, o método alterar conforme abaixo:



Assim, ao clicarmos no ícone do lápis, abrindo o Modal com os dados de usuário e senha, alterando a senha e clicarmos no botão Alterar, a mensagem abaixo é mostrada:

6.11.3 Desabilitando o usuário Iremos agora fazer uma rotina que ao clicarmos no ícone da lixeira, será perguntado ao usuário se o mesmo deseja desativar o referido. Para isso precisamos implementar a função JavaScript desativa_usuario() atrelada ao botão, na v_usuario.php, vejam:



Feito isso, agora vamos implementar a Controller usuário e acrescentar o método desativar(), vejam:



Agora para finalizar implementaremos na Model m_usuario o método desativar(), segue:

Quando clicamos no botão com a lixeira aparece a mensagem conforme abaixo:

Caso confirme, o status do usuário é passado para “D”. 6.12 Resultados da atividade prática Nas duas últimas semanas vocês desenvolveram uma atividade prática, com algumas melhorias nessa tela de cadastro de usuários como:

1º - No banco de dados, na tabela de usuários, criaram um campo TIPO, onde deveria armazenar o tipo de usuário do sistema, sendo: “ADMINISTRADOR” ou “COMUM”;

2º - Na página de cadastro e alteração e na bootstrap table de consulta, adicionar esse campo;

3º - Realizar a validação de usuário já cadastrado;

4º - E ao informar a senha, o usuário deveria ter um campo para confirmar a senha e fazer a validação, tanto no cadastro, quanto na alteração, se não forem correspondentes não permitir o salvamento.

É o que chamamos de validação/integridade das informações, é claro que temos mais

opções de validação, mas o principal objetivo era que vocês passassem por uma situação real de validação em um sistema.

A seguir implementei uma solução para tais validações, é claro que vocês precisam ter essas validações feitas em vosso sistema para a sequência de nossas aulas, e também é claro que não precisa estar igual as nota de aula, mas as validações precisam estar iguais.



6.12.1 Criação do campo tipo de usuário Usando o MySql Workbench fizemos a alteração na tabela de usuários como a seguir:

6.12.2 Criação dos campos tipo de usuário e validação de senha na página principal No código abaixo já implementamos o campo tipo de usuário e mais o campo de validação de senha como a seguir:

6.12.3 Criação dos campos tipo de usuário e validação de senha na modal No código abaixo já implementamos o campo tipo de usuário e mais o campo de validação de senha, agora na modal, vejam:



6.12.4 Alterando o bootstrap table E agora alterando o bootstrap table, acrescentando a coluna tipo de usuário e aproveitei para colocar o status que abordaremos mais a frente, vejam:

6.12.5 Validação do usuário já cadastrado Agora fazendo a validação do usuário, criamos no “onblur” do id usuário no HTML uma chamada para a função Verifica() no JavaScript, vejam:

Agora sim a função:



Percebam que através do Ajax chamamos a controller usuario com o método verusu passando como parâmetro o usuário digitado, vejam o método abaixo:

Agora chamamos a model m_usuario com o método verusu, vejam:

6.12.6 Validação da senha

Para a senha informada criamos uma validação para que a mesma fosse informada corretamente, deveria ser realizada tanto no cadastro como na alteração, vejam no cadastro:



Vejam na alteração:

6.12.7 Salvamento da inserção e alteração dos dados Com essa nova implementação a inserção e alteração de dados, tanto na controller e na model só precisaram ser acrescentados os campos, vejam Controllers: - Salvamento:

- Alteração:



Models: - Salvamento:

- Alteração:

6.13 Habilitando um usuário já excluído Para finalizarmos o cadastro de usuário, iremos implementar agora a reativação do mesmo, o layout será parecido com o abaixo:



Para isso acontecer, a primeira tarefa é alterar a consulta da tabela, retirando da cláusula WHERE o estatus = “” e melhorar a querie para que a mesma traga o status já no resultado da mesma, vejam abaixo:

Percebam que utilizamos o CASE WHEN no SELECT para definirmos a escrita “DESATIVADO” e “ATIVADO” no status. Após isso modificamos o método consultar() na model m_usuario, vejam:

Agora faremos uma modificação no código existente, quando o status do usuário for “DESATIVADO” iremos mudar o ícone da coluna ação, habilitando um ícone para reativação do mesmo, para isso precisaremos alterar o código no JavaScript na função opções, vejam:

Agora na função passo mais dois parâmetros, row e índex, no caso utilizaremos o parâmetro row, onde nos permite naquela linha da tabela, pegar o valor de qualquer coluna, percebam que na comparação (if) usamos o row.estatus, ou seja naquela determinada linha da



tabela na coluna status eu verifico o conteúdo da coluna, caso esteja “DESATIVADO” é nomeado um ícone para reativação do usuário e chamada para função reativa_usuario(), caso contrário permanece o que implementamos nas nossas primeiras aulas. Vejam:

Agora no JavaScript vamos criar a função reativa_usuario(), vejam:



Na controller usuario criamos mais um método para tratar a reativação, o reativar(), vejam:

Na model m_usuario fazemos o método também chamado reativar(), ficando assim:



6.14 Menu Sair Vamos implementar a rotina de saída do sistema que está no menu SAIR, para isso vamos no arquivo menu.php que está na pasta VIEWS -> INCLUDES e acrescentar conforme abaixo:

Agora na controller LOGIN criaremos o método Logout conforme abaixo:

Sendo assim, toda vez que clicarmos no SAIR no menu de nosso sistema, o mesmo retornará para a tela de login e destruirá a sessão que estava ativa. 6.15 Exercício para entrega No sistema atual, implementem a seguinte rotina: Só poderão acessar o menu “Cadastro->Usuários” os usuários que forem do tipo administrador e status em branco, caso contrário, ao clicar nesse menu deve ser informado que o mesmo não possui direito de acesso. Implementem e chamem o professor para validação, vocês terão até o dia 08/11/2018 para apresentar essa solução, atividade deverá ser desenvolvida individualmente.

ensino tÉcnico notas de aulas ds ii 1 - marcoscosta.eti.br de aulas dsii.pdf · documentação...

Documents