Jquery e JqueryUI

O jQuery é uma nova biblioteca do JavaScript. Anunciada oficialmente pela primeira vez em 14 de janeiro de 2006 por seu criador John Resig em uma sessão de demonstração de projetos em um feira chamada BarCampNYC Wrap-up (RESIG, 2006).

O jQuery é uma maneira rápida, concisa e simples de acessar e percorrer os elementos HTML. Através disso, um desenvolvedor pode manipular eventos fazendo animações e interações Ajax para um rápido desenvolvimento web (JQUERY, [s.d.]).

Resumindo, o jQuery foi projetado para mudar a maneira que o desenvolvedor escreve JavaScript.

De acordo com site do projeto (JQUERY, [s.d.]), suas principais características são:

 Rápido e leve – Em sua atual versão 1.6.2, a biblioteca pode ser utilizada para a produção através de um arquivo de 31KB;

 Suporte aos seletores CSS 1 ao 3; e

 Cross-browser – é funcional em todos os navegadores, incluindo suas versões mais antigas, como é o exemplo do Internet Explorer 6 que é o terror dos desenvolvedores por causa de sua má interpretação dos elementos HTML e CSS.

Já o jQuery UI, fornece abstrações de baixo nível de interação e animação, efeitos avançados e de alto nível, widgets personalizáveis, construído em cima da

biblioteca JavaScript jQuery, e pode ser usado para construir aplicações web altamente interativas (JQUERY UI, 2010).

O jQuery UI, assim como o jQuery, tem seu código aberto, ou seja, qualquer um pode usar e também colaborar para o crescimento e o melhoramento da biblioteca.

O jQuery UI possui também internamente um framework poderoso para a criação de temas chamado ThemeRoller. Este framework possui ferramentas que torna a criação de temas, para as aplicações, rápida e fácil, como pode ser observado na Figura 9.

Figura 9 - ThemeRoller - Framewok para criação de temas no jQuery UI.

Fonte: Jquery UI (2010).

Como podem visualizar na figura acima, a interface do ThemeRoller é dividida em painéis para font global e definições de raio de canto, estilos dos containers, e os estados de interação para os elementos clicáveis, e vários estilos para sobreposições e sombras. Estes painéis permitem a configuração de várias

propriedades CSS tais como tamanho e cor da fonte, cor e textura do fundo, cor da borda, cor do ícone, raio de canto, etc.

3.5.4 Code Igniter

O Code Igniter é um framework de desenvolvimento de aplicativos para quem constrói sites em PHP. Seu objetivo é permitir que o desenvolvedor desenvolva projetos mais rapidamente do que poderia se estivesse escrevendo o código do zero, proporcionando um rico conjunto de bibliotecas para as tarefas mais comuns necessárias, bem como uma interface simples e estrutura lógica para acesso aquelas bibliotecas. O CodeIgniter permite que o desenvolvedor mantenha o foco em seu projeto minimizando a quantidade de código necessário para uma dada tarefa (ELLISLAB, INC., 2011).

De acordo com o Guia do usuário, escrito pela empresa mantenedora do projeto Ellislab (2011) e seus contribuintes, o CodeIgniter é ideal para o desenvolvedor que:

 Quer um framework leve com um grau de aprendizado pequeno;

 Precisa de um desempenho excepcional;

 Precisa de compatibilidade entre os servidores de hospedagens;

 Quer um framework que requer uma configuração quase zero;

 Quer um framework que não requer que você use a linha de comando;

 Não quer ser forçado a aprender uma linguagem de templates (embora um parser de template esteja disponível opcionalmente, se você desejar um); e

 Precisa de documentação clara e completa.

Além disso, o Code Igniter utiliza o padrão de arquitetura de software MVC (Model, View, Controller) que separa a lógica de negócio da lógica de apresentação, permitindo um melhor controle na criação de softwares entre equipes, pois permite o desenvolvimento, teste e manutenção isolado de ambos.

O padrão MVC é composto por três camadas, model, view e controller. Cada camada será responsável por executar funções distintas dentro da aplicação e o núcleo do framework irá fazer a comunicação entre as camadas.

A camada Model (modelo) é a responsável por fazer a interação com o banco de dados. É o Model que tem contato com as informações armazenadas e que são mostradas ao usuário final. É no Model e somente no Model que as operações de select, insert, update e delete devem acontecer.

A camada View (visão), é a apresentação, é o que aparece, é o que é visualizado pelo usuário do sistema. É na View que todas as informações, incluindo às buscadas na Model, serão exibidas. É nessa camada também, que será aplicado o design da interface e a estrutura organizacional para que seja um ambiente agradável ao usuário final.

Já a camada Controller (controlador), como o próprio nome sugere é o responsável por controlar todo o fluxo do sistema. O controller é o ―cérebro‖ e o ―coração‖ da aplicação. È esta camada que faz comunicação entre a camada model e a camada view, desde o que vai ser consultado no banco de dados à tela que vai ser exibida para o usuário que usa o sistema.

A Figura 10 mostra o fluxo do sistema, criado com o codeigniter juntamente com o padrão de arquitetura MVC que está destacado, mostrando a comunicação entre as camadas e como as requisições são tratadas.

Figura 10 - Fluxo de dados do codeigniter.

3.6 Controle de Versão

Muitos problemas de desenvolvimento acontecem por falta de controle de versão. Imagine o seguinte cenário:

 Você está desenvolvendo um sistema para web faz mais de um mês. A versão beta já está no ar e você decide fazer algumas alterações. Porém por algum motivo, suas alterações fizeram o sistema parar totalmente e você não consegue encontrar onde foi que errou.

Cenário como esse é bastante comum no mundo do programador. Agora imagina um sistema assim, sendo alterado todos os dias por uma equipe de desenvolvedores. Teria muitos erros e códigos subscritos sem saber quando foram feitos e quem fez, além das dificuldades em recuperar o código de uma versão anterior que está em produção.

Para a resolução desses problemas existem os sistemas de controle de versões, VCS (do inglês Version Control System) ou ainda SCM (do inglês Source Code Management). O controle de versão subdivide-se em duas partes: o

repositório e a área de trabalho.

No repositório é armazenado todo o histórico da produção de um projeto. Toda alteração efetuada é registrado juntamente com o usuário que o fez em cada versionamento. Portanto, caso um usuário fizer uma alteração errada em algum arquivo, é possível voltar para uma versão anterior sem maiores transtornos.

O desenvolvedor nunca trabalha diretamente com os arquivos do repositório. Ele faz uma requisição e com isso cria-se uma área de trabalho, isolada dos demais, com a cópia dos arquivos do projeto. Cada alteração feita é monitorada pelo controle de versão. Após o desenvolvedor efetuar todas suas alterações é preciso enviar os arquivos sincronizando com os do servidor.

Segundo Dias (2011), existem dois tipos de controle de versão: o

centralizado e o distribuído. No controle de versão centralizado existe apenas um

repositório central e cada desenvolvedor tem sua área de trabalho. Já, no controle de versão distribuído, pode existir vários repositórios onde um pode ser usado para convencionar o fluxo do trabalho e cada repositório pode ter vários desenvolvedores.

Existem várias ferramentas disponíveis para o controle de versão. Porém, de acordo com Dias (2011), o recomendado para o controle de versão centralizado é o

Subversion e para quem desejar utilizar distribuído o Mercurial ou o Git.

Para fazer o controle de versão do sistema Brasilleiro foi utilizada a ferramenta Mercurial com o tipo distribuído. Esta ferramenta foi escolhida porque existe um site chamado Bitbucket, da empresa australiana Atlassian, que serve para o armazenamento de repositórios distribuídos, como Mercurial e Git, e que se difere dos demais concorrentes por permitir ilimitados repositórios públicos e privados (MADDOX, 2011).

No Bitbucket existem diversos projetos armazenados, incluindo o Brasilleiro (OLIVEIRA, 2011). Atualmente o repositório do Brasilleiro encontra-se privado sendo mantido, atualizado e sincronizado apenas por um usuário. Mas o momento que o administrador achar conveniente incluir novos usuários ou alterar sua visualização e edição aberto ao público, basta apenas alguns cliques e o sistema passa a ser desenvolvido, por uma equipe ou qualquer desenvolvedor interessado.

Na Figura 11, pode-se observar a página que exibe os versionamentos do sistema Brasilleiro. No primeiro destaque, está o endereço do repositório caso um usuário, com permissão de acesso, possa fazer um clone dos arquivos e criar sua área de trabalho. No segundo destaque, aparece o número total de versões feitas no projeto. E no terceiro destaque estão os últimos versionamentos do sistema, mostrando a data que foi efetuada, a descrição das alterações, o código da revisão e quem enviou.

Figura 11 - Versões do projeto Brasilleiro no Bitbucket.

Fonte: Bitbucket ([s.d.])

3.7 Recursos Implementados

Este tópico apresenta uma breve descrição de cada um dos recursos implementados neste protótipo, destacando suas principais funções.

3.7.1 ACL

Access Control List (ACL) é a Lista de Controle de Acesso dos usuários. Esta lista define quais usuários vão ter permissão de acesso aos serviços. Esta prática é normalmente usada para servidores de rede, onde o administrador atribui os tipos de acesso aos grupos de usuários.

No Brasilleiro foi aplicado o conceito de ACL, por se tratar de uma forma bastante dinâmica e simples de implementar. Este conceito, por abranger três recursos, vamos tratar como um módulo do sistema.

Primeiramente, para um cidadão ter acesso ao sistema, o mesmo deve já possuir um login e senha ou efetuar o cadastro. Caso a segunda a opção for escolhida, o cidadão será encaminhado para uma nova página onde deverá preencher, no formulário de cadastro, alguns campos requeridos, tais como nome, email, senha e a cidade caso não houver sua prefeitura disponível. Por padrão, o novo usuário cadastrado vai pertencer ao grupo dos cidadãos e possuir todos os privilégios que o grupo disponibiliza.

Na Figura 12 é possível visualizar o formulário de login, à esquerda, e o de cadastro de novos usuários, à direita.

Figura 12 - Páginas de login e cadastro de usuários.

Fonte: Protótipo do Brasilleiro.

O administrador do Brasilleiro possui acesso a todos os recursos do sistema. Isso inclui o gerenciamento do módulo ACL que abrange as páginas dos recursos,

grupos e usuários. Através destes, o usuário tem controle total sob o sistema,

podendo cadastrar e excluir recursos, grupos e usuários.

3.7.1.1 Recursos

Neste item, o administrador gerencia todos os recursos disponíveis no sistema (ver Figura 13).

Os campos do formulário de cadastro são:

 Nome do recurso;

 Nome identificador – este nome servirá para o sistema verificar se um usuário possui privilégios de acesso ao recurso;

 Descrição – uma breve descrição sobre o que o recurso faz;

 Este recurso pertence ao: Sistema de prefeituras ou Sistema administrativo Brasilleiro; e

 Situação – ativo ou inativo. Caso o recurso estiver inativo, nenhum usuário poderá acessá-lo;

Figura 13 - Formulário de cadastro dos recursos.

Fonte: Protótipo do Brasilleiro.

3.7.1.2 Grupos

Os grupos são peças fundamentais dentro do sistema administrativo da ferramenta. Cada usuário precisa obrigatoriamente pertencer a um grupo, que por sua vez é vinculado aos recursos.

Atualmente existem apenas três grupos principais no Brasilleiro, como podemos observar na Figura 14. O Administrador Master possui acesso total ao sistema administrativo. O Administrador de Prefeituras possui acesso às páginas de cadastros da prefeitura que o usuário pertence. Já o Cidadão têm acesso apenas ao seu painel de controle, podendo fazer alterações em seu próprio perfil e interagir com alguns recursos como comentários nas notícias, enviar novas imagens nas galerias, entre outras.

Figura 14 - Relatório dos grupos de usuários cadastrados.

Fonte: Protótipo do Brasilleiro.

O formulário de cadastro dos grupos contêm os seguintes campos (ver Figura 15):

 Nome do grupo – exemplo: Administrador Master;

 Situação do grupo – ativo ou inativo. Caso o grupo estiver inativo, seus usuários não poderão entrar no sistema;

 Descrição do grupo;

 Recursos – nesta tabela são escolhidos quais recursos o grupo terá acesso e quais os privilégios de cada um;

Figura 15 - Formulário de cadastro dos grupos.

3.7.1.3 Usuários

Como o próprio nome já sugere, esse recurso é responsável por gerenciar todos os usuários cadastrados no sistema (ver Figura 16). Através deste recurso é possível:

 cadastrar, editar e excluir usuários;

 escolher o grupo que o usuário vai pertencer;

 escolher seu endereço entre as prefeituras cadastradas ou através do nome da cidade;

 alterar a senha dos usuários;

Figura 16 - Formulário de cadastro dos usuários.

3.7.2 Gerenciamento de prefeituras

O recurso Gerenciamento de prefeituras é um dos principais recursos do sistema. Através deste, é possível cadastrar, editar e excluir as prefeituras que escolheram o Brasilleiro como sua ferramenta para criação do portal. Porém, somente os usuários que pertencem ao grupo Administrador Master são os que podem acessar as páginas de cadastros.

Antes de efetuar o cadastro de uma prefeitura é preciso ter um tema definido. No tema é personalizado o design e a estrutura das informações do portal. Portanto é preciso efetuar o cadastro de um tema para cada prefeitura, onde a partir de um formulário de cadastro faz-se o upload de um arquivo no formato zip que contém todos os arquivos necessários para a visualização do portal.

Após o cadastro do tema, é possível adicionar os dados da prefeitura e concluir seu cadastro. No formulário de cadastro (ver Figura 17) são requeridos alguns dados importantes que são necessários para sua identificação:

 Estado e Cidade que a prefeitura pertence;

 Domínio – por exemplo: www.ijui.rs.gov.br. Todas as prefeituras precisam obrigatoriamente ter um domínio. Além deste domínio, os usuários também poderão acessar o portal da prefeitura através do seguinte endereço: www.brasilleiro.com.br/nomedacidade_rs.

 Situação – ativo ou inativo. Caso a prefeitura estiver inativa, seu portal não poderá ser visualizado.

 Descrição – uma breve descrição da prefeitura; e

 Tema – faz-se a escolha do tema que vai conter o design e a estrutura do conteúdo do portal;

Figura 17 - Formulário de cadastro de prefeituras.

Fonte: Protótipo do Brasilleiro.