Desenvolvimento do Projeto

Criação dos models:

A função dos models é descrever algo real no código, por exemplo um dos models criados neste projeto foi o “Software” que continha vários atributos dos quais se destacam o “software_brand” que é a marca do software (objeto do tipo “Software”) e “reception_date” que é a data de quando este

software foi adquirido, o que significa que qualquer objeto existente ou que venha a ser criado na

base de dados do tipo “Software” vai ser descrito por diversos atributos como os que foram referenciados anteriormente.

Os Models são uma classe que representa uma tabela numa base de dados que armazena propriedades, atributos e ações (model field) e que representam uma coluna da tabela na base de dados. Cada um destes models contém os seus respetivos atributos e um ID que também é considerado um atributo com a diferença de este ser único para cada objeto, isto é cada objeto criado pelo utilizador vai tem um ID único que não pode ser igual ao ID de outro objeto.

Para que cada objeto tenha o seu ID único foi criada uma função dentro de cada uma das classes denominada de “generate_id” que tem como função gerar automaticamente um ID sempre que é criado um novo objeto.

É necessário definir estes tipos de objetos no ficheiro “models.py”. Neste ficheiro vão ser criadas classes para cada um dos tipos de objetos e os atributos que cada classe vai possuir.

Figura 20 - Parte do código do model CPE Fonte: Projeto desenvolvido

Como se pode observar na figura 20, inicialmente foi definida uma classe com o nome “Cpe” com diversos model fields dos quais se destacam “cpe_id”, “brand”, “service_provider” e “model”.

Na figura 20 apenas foram criados model fields do tipo CharField, o que significa que o conteúdo dessas colunas vai ser do tipo string. Contudo há outros tipos de model fields, como DateFields que também foram utilizados neste projeto, e a diferença deste tipo em relação ao anterior é que as colunas definidas desta forma só podem conter datas.

21

Outra característica é que todas estas colunas devem estar preenchidas obrigatoriamente pois um dos atributos é “Null=False” que significa que essa coluna não pode estar vazia. Para além deste atributo é obrigatório atribuir sempre o número máximo de carateres que aquele model field deve ter, caso contrário o Django vai apresentar um erro alertando para que “max_length” não está definido.

Os restantes models (Hardware e Software) foram criados da mesma forma e diferem apenas no nome da classe que os define e no nome dos model fields que cada um tem.

Por fim ao criar um model é necessário transmitir à base de dados a criação de novos models e o mesmo é efetuado através de migrations.

Quando os models são criados, não são colocados diretamente na base de dados, é necessário executar certos comandos no terminal para que na base de dados sejam criadas as tabelas respetivas aos models criados.

Inicialmente executa-se o comando “python manage.py makemigrations catalog_site” e este comando transmite a informação à base de dados sobre a forma como as tabelas são constituídas, como por exemplo o nome de cada uma e que atributos vai ter.

Para finalizar é necessário confirmar as alterações feitas na base de dados, ou seja, é necessário que o utilizador confirme que realmente quer alterar a base de dados. Este último passo é feito através do comando “python manage.py migrate”. Este processo de confirmação pode ser observado na figura 21.

Figura 21 - Exemplo de Migrations Fonte: Projeto Desenvolvido

22

Criação de Model Forms:

Através da criação dos models já era possível mostrar, através das páginas HTML, os model fields e assim o utilizador fazer uso dos mesmos. No entanto, o Django disponibiliza a classe Form que vai tratar da interface das páginas web.

A classe form, semelhante à classe model, descreve a estrutura lógica de um objeto, o seu comportamento e a maneira como vai ser organizada e apresentada a interface do mesmo ao utilizador. Tal como a classe model que mapeia os model fields para a base de dados, a classe form mapeia os form fields para os elementos “<input>” do formulário HTML.

Resumidamente, a classe form descreve um formulário e determina o seu funcionamento e interface. Quando é criado um form, é possível deixá-lo vazio ou preenchê-lo com:

 dados provenientes/baseados de um model guardado previamente ;

 dados obtidos através de outras fontes;

 dados recebidos por um post de um formulário do utilizador.

Neste projeto todos os forms criados eram baseados nos models ou seja quando era criado um form, o mesmo ia conter form fields (campos de preenchimento do formulário) correspondentes aos fields do

model em que era baseado.

Por exemplo se um model field for definido como Charfield, posteriormente o form criado e correspondente a esse model, vai ter um form field do tipo Charfield.

Com os forms é possível fazer validações do conteúdo que o utilizador está a colocar em cada model

field e isto é vantajoso, pois vai haver uma validação do que está a ser inserido ou editado e caso

esses dados estejam incorretos o utilizador não vai poder finalizar a ação que estava a realizar no

website e será avisado qual é o erro que provoca isso.

Assim sendo foram criados diversos forms, no ficheiro “forms.py”, baseados em models previamente criados.

Na criação de forms também é definido o tipo de conteúdo e a forma como o respetivo campo de preenchimento irá ser mostrada ao utilizador através de CharFields e ChoiceFields, entre outros.

23

Tal como na classe model, a classe form vai ter atributos que vão definir como este campo vai ser mostrado ao utilizador, isto é, nestes atributos vão estar dados relativos ao tipo de campo de preenchimento que vai aparecer (o seu tamanho e a label que vem com ele, entre muitas outras opções). Nos forms criados, para além dos atributos já referidos, foram adicionados atributos que controlam o número máximo de carateres, bem como se o preenchimento dos forms é obrigatório ou não.

Como é possível observar na figura 22, depois de ser definida a classe form, neste caso “HardwareForm”, é necessário transmitir ao Django qual é o model em que este form se vai basear. O mesmo é feito através da “classe Meta”. Para além de definir em que model é baseado, é necessário identificar os campos desse model que vão estar relacionados com os fields do form. É ainda importante referir que na construção do form, a forma que o Django usa para relacionar os

fields com os model fields criados é a ordem de escrita, contudo depois na construção do HTML já

não é necessário ser rigoroso na ordem pela qual os campos de preenchimento aparecem.

URLS:

Após a criação dos models e dos forms é necessário criar urls das páginas.

Url é o endereço de um recurso disponível numa rede, ou seja, o url é o path (caminho) que indica a

localização do que o utilizador procura quer seja um aquivo, um website ou até mesmo um dispositivo periférico como uma impressora.

Estrutura do url:

Um url é constituído por esquema, domínio, porta (opcional) e path, e tal como a porta o url pode ser constituído opcionalmente por um query string e um fragment.

Exemplo: http://127.0.0.1:8000/catalog_site/details/AMLC01021

 Esquema é o protocolo que poderá ser HTTP, HTTPS, FTP etc.

Figura 22 - Parte do código do model form Hardware Fonte: Projeto Desenvolvido

24

 Domínio é o endereço da máquina que designa o servidor que disponibiliza o documento ou recurso solicitado pelo utilizador. No exemplo acima, o endereço da máquina é 127.0.0.1 que o localhost (o próprio computador do utilizador)

 Porta é o ponto lógico no qual se pode executar a conexão com o servidor. No exemplo acima a porta é o 8000.

 O path especifica o local onde se encontra o recurso no servidor (catalog_site/details).

 A query string é um conjunto de um ou mais pares "pergunta-resposta" ou "parâmetro- argumento" (neste caso id=AMLC01021, em que o id é uma variável (neste caso é um atributo de um objeto), e AMLC01021 é o valor a essa variável). Resumidamente, o que este pedaço do url faz é enviar uma string ao servidor para que seja possível filtrar o recurso, ou seja vai dizer ao servidor para ir buscar o recurso que tem o id AMLC01021.

 O fragment é uma parte ou posição específica dentro do recurso.

Neste projeto, um dos ficheiros foi criado automaticamente e esse ficheiro vai conter apenas dois

urls.

A criação dos urls consiste apenas em definir o path, como o mesmo vai ser constituído e que possíveis funções vão estar associadas.

Figura 23 - Urls presentes no ficheiro "urls" criado automaticamente Fonte: Projeto Desenvolvido

O primeiro url que pode ser observado na figura 23 foi criado automaticamente com o ficheiro e direcionava o utilizador para uma página admin do website, porém essa funcionalidade não foi desenvolvida, pois o que estava planeado era apenas a construção de um website funcional onde não existiam tipos de usuários e restrições.

Na criação de um url é necessário definir qual o path que vai ter bem como o que vai acontecer ao aceder a esse url.

25

Como se pode observar na figura 23, na criação de urls a parte inicial é comum a todos (“r’^”) e só diferem a partir daí. Isto deve-se ao facto de que o que é escrito a seguir a esses três carateres vai ser o path do url. Por exemplo, o terceiro url coloca “catalog_site” no path e de seguida, através do código “include(catalog_site.urls)”, transmite ao Django que esse mesmo path pode ter continuação e que essa mesma continuação vai estar no ficheiro “urls” presente na pasta “catalog_site”.

Já o segundo url o que faz é dizer transmite Django que caso path esteja vazio, vai fazer um redirecionamento para o terceiro url. Este redirecionamento é feito através do código “RedirectView.as_view(url=’catalog_site/’, permanente=False)”.

Na prática o que acontece é passar o endereço, neste caso do localhost (“127.0.0.1:800”) para “127.0..0.1:800/catalog_site/” em que “127.0.0.1:800” são o domínio e a porta.

Em relação ao segundo ficheiro dos urls.py, todos os urls definidos vão funcionar de forma semelhante, com a diferença de que os mesmos serão uma continuação do url “catalog_site” definido anteriormente (figura 24).

Isto significa que o path começa sempre por “catalog_site/” e vão sendo acrescentados carateres de acordo com o que o utilizador vai solicitar no website ou funcionalidades a que vai aceder.

A função destes url é executar métodos/funções definidos no ficheiro “views.py”. Tomando o segundo url como exemplo, é possível observar que o path desse url é “index” e é seguido pelo código ”views.main”. O que isto faz é transmitir ao Django que quando este endereço url é utilizado, o website deve executar o método “main” presente no ficheiro “views.py”.

Os restantes funcionam todos da mesma forma e mudam apenas na constituição do path e no método que é executado.

Figura 24 - Alguns dos urls presentes no ficheiro "urls" criado posteriormente Fonte: Projeto Desenvolvido

26

Views e Templates

Como foi referido anteriormente, ao criar o projeto é criado automaticamente um ficheiro Python denominado de “Views”. Este ficheiro contém funções Python, que recebem um pedido e retornam uma resposta.

Por convenção, este tipo de funções são colocadas neste ficheiro, daí o facto de ter sido criado automaticamente.

As views, de uma forma geral são compostas por uma função criada pelo programador e que, através de um url, está ligada a um template específico. Templates são as páginas HTML através das quais o utilizador consegue visualizar e interagir com as mesmas, onde faz pedidos e recebe respostas por parte da aplicação. De forma resumida, essa é a função dos templates uma vez que os navegadores

web não conseguem traduzir linguagens de programação como o Python e é necessário haver uma

forma de gerar código HTML e Python para que o website não se torne estático.

Um template contém código HTML que mostra o output do website ao utilizador e contém ainda uma syntax especial para que seja possível a ligação entre HTML e Python podendo assim criar páginas web interativas.

O funcionamento destas funções é efetuado sempre da mesma forma. Inicialmente o utilizador envia um pedido ao servidor (request) através de um url que que contém as informações do pedido. De seguida, o servidor analisa o pedido e retorna uma resposta através de um template ou da execução de uma ação (Figura 25).

Figura 25 – Interação entre o utilizador, plataforma web e servidor Fonte: http://django-easy-tutorial.blogspot.pt

27

Neste projeto foram criadas diversas views para que fosse possível interagir com a aplicação de diversas formas, das quais se salientam adicionar, editar objetos e visualizar os detalhes quer de um objeto apenas quer de uma lista inteira de objetos presentes na base de dados. E para cada uma

Lista de todos os equipamentos da base de dados:

Ao iniciar a aplicação, a página inicial é composta por uma lista de todos os equipamentos do laboratório bem como algumas das características que possuem. Para além da lista, existe um botão “Add” que permite ao utilizador adicionar novos equipamentos à lista. Por fim a página inicial tem uma sidebar onde o utilizador pode escolher que tipo de equipamento deseja ver (CPE, Hardware, Software) e ainda a opção de ser redirecionado para a página que trata das requisições dos equipamentos da equipa. Estas funcionalidades podem ser observadas no Anexo 3.

Na prática o que acontece é que o utilizador, ao iniciar a aplicação, está a efetuar um pedido ao servidor, através do url da página inicial. De seguida, o servidor lê e processa o pedido e vai retornar o template da página inicial.

Como foi explicado anteriormente, quando o utilizador acede a uma página web, a mesma tem um

url que vai executar um método e neste caso será o método “main”. Esta função é que é responsável

pelo processamento do pedido realizado e pelo retorno do mesmo.

O que acontece é que a função vai guardar todos os dados dos models (CPE, Hardware e Software) presentes na base de dados e guardá-los num dicionário denominado de “context”. E de seguida vai retornar o template da página inicial preenchido com os dados guardados, neste caso as tabelas com os dados de todos os models (figura 26).

Figura 26 - Código da função main Fonte: Projeto Desenvolvido

28

Depois de criada a função que possibilita a visualização do conteúdo da base de dados é necessário criar um template que essa função vai retornar (Figura 27). Como é possível observar no Anexo 3, o

template do menu inicial mostra os equipamentos e os seus atributos através de uma tabela.

Figura 27 – Parte do código do template da lista de equipamentos Fonte: Projeto Desenvolvido

Inicialmente cria-se a tabela e de seguida definem-se os headers da mesma (“<th> … <th>”), que são os nomes que descrevem o conteúdo que cada coluna vai ter.

É necessário preencher a tabela com os dados da base de dados. Assim sendo, foi criado um ciclo que vai procurar cada um dos objetos presentes na lista de dados e mostrá-los na tabela. Uma vez que a linguagem HTML é estática, é necessário colocar quer o ciclo “for” quer os dados dos objetos entre “{}” de forma a dizer ao Django que aquelas linhas são código Python. Ao longo do projeto, na criação de templates foi muito utilizada esta syntax tornando assim a plataforma web interativa. No que diz respeito à mudança entre as listas de tipos de equipamentos, esta é feita através de JavaScript. Basicamente, o JavaScript criado o que vai permitir que quando o utilizador prime, por exemplo, o botão Software, as listas Hardware e CPE vão ficar invisíveis e a lista Software não (figura 28).

Figura 28 - Script “hw_change()” Fonte: Projeto Desenvolvido

29

Para além dos botões referidos anteriormente existe ainda o botão “Requisition” presente na sidebar e o botão “Add”. Ambos têm funções e funcionamentos semelhantes. O botão “Requisition” tem como função redirecionar o utilizador para a página das Requisições de material, já o botão “Add” redireciona o utilizador para o formulário de adicionar equipamentos à base de dados. Tudo isto é realizado através do atributo “href”. Este atributo contém um url definido, neste caso o url do

template das páginas de Requisições e do formulário de adicionar equipamentos e quando o botão é

pressionado, o utilizador é redirecionado para a página HTML correspondente a esse template.

Adicionar Dados:

Quando o utilizador prime o botão “Add” no menu principal é direcionado para uma página HTML que tem um formulário para adicionar novos objetos à base de dados com diversos campos de preenchimento, como é possível observar no Anexo 4.

Para criar o template de adicionar equipamentos é necessário existirem três formulários diferentes para cada um dos tipos de objetos nesse template. Apesar da diferença, entre eles o código HTML dos três formulários é semelhante e só muda os nomes dos model fields, já que a estrutura é igual. Mas antes de referir os formulários é importante referir e explicar certas linhas de código que têm um papel importante para o correto funcionamento de qualquer página HTML que implique a gestão de uma base de dados.

Figura 29 – form Fonte: Projeto Desenvolvido

A linha <form action=”…” method=”post” … <form> é muito importante na medida em que vai especificar como é que os dados vão ser enviados para uma determinada página.

O atributo “action”, através do url, indica qual é a localização para onde os dados serão enviados. Neste caso os dados serão enviados para a página “add_item.html” como se pode observar na figura 29.

Já o atributo “method” define como é que os dados vão ser enviados. Há diversas formas de enviar dados mas as mais comuns são através do método “get” e “post”. Quando são pedidos os dados através do método “get”, o servidor retorna os dados pelo url, porém o objetivo é receber os dados no

30

body do HTML, na própria página e não na barra de endereços. Por essa razão é que é usado o

método “post” e através deste método a resposta que o servidor vai enviar ao utilizador é no body da página e não no url.

Posto isto é possível passar à criação do template do formulário de adicionar itens/equipamentos. Como é possível observar no Anexo 4, o formulário é constituído por diversos campos de preenchimento de acordo com o tipo de equipamento que o utilizador pretende adicionar e um botão “Submit” que irá guardar todos esses dados na base de dados. O código relativo a cada campo de preenchimento é muito semelhante entre eles como se pode observar na figura 30.

Figura 30 - Parte do código do template de adicionar equipamentos Fonte: Projeto Desenvolvido

Para explicar o código vou tomar, como exemplo, o bloco do código relativo ao campo preenchimento do “model” presente na figura 30.

Na primeira linha o código “form_cpe.model.label_tag” acede aos forms criados anteriormente no ficheiro “forms.py”, mais especificamente ao “form_cpe” buscar a label definida no field do “model”. Na linha seguinte “form_cpe.model” vai buscar que tipo de field é, neste caso é um CharField que é uma caixa de texto para inserir dados. Caso o tipo de field fosse ChoiceField como é o caso do model field “brand” é apresentada uma drop-down list com opções para o utilizador escolher como se pode observar no Anexo 4. Por fim a última linha tem como função avisar o utilizador de erros. Caso o utilizador tente submeter um dado incorreto, vai surgir uma alert box que é um pequeno texto debaixo do campo incorreto a avisar o utilizador que o valor que está a tentar submeter está incorreto como se pode observar na figura 31.

31

Figura 31 - Alert box Fonte: Projeto Desenvolvido

Como já foi referido, a página “Add Items” é um formulário para adicionar novos equipamentos à base de dados, porém existem três tipos de equipamentos diferentes. Isto significa que quando o utilizador acede à página tem de existir a possibilidade de escolher que tipo de equipamento quer adicionar e só pode aparecer o formulário de adicionar relativo a esse tipo de equipamento. Portanto, é preciso existir uma forma de separar os formulários dos diferentes equipamentos. Devido a isso foi criado um JavaScript semelhante ao do menu inicial que torna os formulários visíveis ou invisíveis de acordo com a opção selecionada na sidebar.

Depois de concluída a construção da interface da página, falta apenas tornar a página funcional, isto é falta permitir que a página receba os dados do utilizador, valide e guarde os mesmos na base de