• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
relatorio 07-07-06.doc
 

relatorio 07-07-06.doc

on

  • 1,553 views

 

Statistics

Views

Total Views
1,553
Views on SlideShare
1,553
Embed Views
0

Actions

Likes
0
Downloads
23
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    relatorio 07-07-06.doc relatorio 07-07-06.doc Document Transcript

    • PROTOREG – Programa piloto de registo de intoxicações alimentares Biostrument, Lda 2005 / 2006 1020515 - Daniel Nogueira Departamento de Engenharia Informática
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Biostrument, Lda 2005 / 2006 1020515 – Daniel Nogueira Departamento de Engenharia Informática Junho de 2006 Orientador ISEP: Constantino Martins Supervisor Externo: Luís Meireles
    • À minha família, namorada e amigos iii
    • Agradecimentos Gostaria de agradecer a todas as pessoas que, de alguma forma deram o seu contributo à realização do projecto. Em especial: - Ao Eng. Constantino Martins por ter aceite ser meu orientador de estágio, e por todo o apoio prestado. - Ao Dr. Luís Meireles pela oportunidade de estágio e por todo o apoio na realização do projecto - Ao meu colega de estágio Ivo Pereira, pelo conhecimentos trocados e esclarecimentos de duvidas. -Aos meus pais e irmãos pelo apoio nos momentos mais difíceis, pois sem eles não teria chegado aqui. -À minha tia e primas por todo o apoio. -À minha namorada por toda a compreensão. A todos o meu muito obrigado. Amarante, Daniel Nogueira iv
    • v
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Resumo As toxinfecções alimentares são um problema de saúde pública a nível nacional e europeu. Torna-se assim necessário um sistema de registo destes casos para dar uma noção mais concreta do problema. Para isso será criada uma plataforma para armazenamento e tratamento dos dados, e um site de publicação dos mesmos. Este relatório apresenta todo o processo de análise de desenvolvimento deste projecto. Numa primeira fase foram analisados todos os requisitos do sistema e foi desenvolvida a base de dados para suportar toda a informação. O site foi implementado em PHP, HTML, Ajax e XML. O PHP juntamente com o HTML permitiram a criação dinâmica das páginas, enquanto que o Ajax e XML foram úteis para fazer algumas comunicações rápidas entre o cliente e o servidor sem a necessidade a refrescamento das páginas. Foram desenvolvidos vários módulos de funcionamento do site. Entre eles salientam-se os mais importantes: • Zona de importação e tratamento de dados recebidos dos hospitais; a esta secção apenas os administradores têm acesso. • Zona de publicação dos dados tratados, aos quais têm acesso todos os indivíduos que visitem o site e depois de se registarem gratuitamente. Esta parte terá gráficos estatísticos que de uma forma intuitiva dão a conhecer a realidade deste problema que são as intoxicações alimentares. • Zona de noticias, onde periodicamente serão publicadas novas noticias relativas ao problema em questão; Daniel Nogueira vi
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • Zona de registo para os utilizadores se registarem e terem acesso à zona de publicação dos dados e à zona de noticias. Actualmente o projecto já se encontra operacional, sendo que a empresa ficou bastante satisfeita com o resultado final. Palavras Chave (Tema): Intoxicações alimentares, hospitais, ASAE Palavras Chave (Tecnologias): Ajax, php, mysql, JavaScript Daniel Nogueira vii
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Abstract The food intoxications represent a national and European strong public health problem. So it’s necessary to create a record system of these cases in order to give a more solid perception of the problem. In such a way, it will be shaped a storage proposal and data management and a publication site for the same ones. This report presents all the analysis process of development of this project. In a first stage all the system requirements were analyzed and the database was developed to support all the information. The site was applied in PHP, HTML, AJAX and XML. The PHP and HTML had been used to the dynamic creation of the pages, while the Ajax and the HTML had been used to do some fast communications between the client and the server without need to refresh the page. Some functioning modules of the site had been developed and the most important are: Importation area and data management received from the hospitals; only the administrators have access to the restricted area. Publication area of the treated data, where everybody can access to the site after their free registration; this part will have statistical graphs that will give us the knowledge to the reality of food intoxications. News area, where it will be published regularly the news about the issue itself. Daniel Nogueira viii
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Registration area, where the users can be able to make their registration and have all the access to the data publication and the news area. Nowadays the project is fully operational, which brings a lot of satisfaction to the company. Daniel Nogueira ix
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Índice AGRADECIMENTOS.............................................................................................................................IV RESUMO...................................................................................................................................................VI ABSTRACT...........................................................................................................................................VIII ÍNDICE DE FIGURAS.........................................................................................................................XIII ÍNDICE DE TABELAS..........................................................................................................................XV ÍNDICE DE EXTRACTOS DE CÓDIGO..........................................................................................XVI 1 INTRODUÇÃO.........................................................................................................................................1 1.1 ENQUADRAMENTO....................................................................................................................................1 1.2 APRESENTAÇÃO DO PROJECTO/ESTÁGIO........................................................................................................1 1.2.1 Objectivo.....................................................................................................................................2 1.2.2 Resultados previstos....................................................................................................................3 1.2.3 Planeamento de projecto............................................................................................................3 1.2.4 Reuniões de acompanhamento....................................................................................................4 2 TECNOLOGIAS UTILIZADAS.............................................................................................................6 2.1 HTML.................................................................................................................................................7 2.2 CSS......................................................................................................................................................7 2.3 JAVASCRIPT............................................................................................................................................8 2.4 PHP.....................................................................................................................................................8 2.5 APACHE.................................................................................................................................................9 2.6 MYSQL.............................................................................................................................................10 2.7 JPGRAPH.........................................................................................................................................10 2.8 XML..................................................................................................................................................12 2.9 AJAX.................................................................................................................................................13 3 AJAX........................................................................................................................................................15 3.1 APARECIMENTO DO AJAX........................................................................................................................15 3.2 TECNOLOGIAS BASE................................................................................................................................18 HTML ...............................................................................................................................................18 DOM (Document Object Model)......................................................................................................18 XML ..................................................................................................................................................18 XMLHttpRequest ..............................................................................................................................18 JavaScript.........................................................................................................................................18 3.3 FUNCIONAMENTO CLÁSSICO DE UMA APLICAÇÃO WEB...................................................................................19 3.4 FUNCIONAMENTO DE UMA APLICAÇÃO WEB USANDO AJAX............................................................................19 3.5 CLASSE SACK.......................................................................................................................................20 3.6 VANTAGENS E DESVANTAGENS.................................................................................................................22 Daniel Nogueira x
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Vantagens..........................................................................................................................................22 Usabilidade.......................................................................................................................................23 Tempos de espera mais curtos..........................................................................................................23 Validações automáticas na submissão de formulários.....................................................................23 Completação automática de campos................................................................................................24 Manipulação de dados altamente interactiva...................................................................................24 Navegação em estruturas em árvore profundas...............................................................................24 Interacção do utilizador com o site..................................................................................................25 Desempenho e compatibilidade........................................................................................................25 Desvantagens....................................................................................................................................26 Usabilidade.......................................................................................................................................26 Implementação..................................................................................................................................27 Dispositivos Móveis..........................................................................................................................28 3.7 CONCLUSÃO..........................................................................................................................................28 4 ANÁLISE E ESTRUTURA DE DADOS..............................................................................................30 4.1 REQUISITOS DO SISTEMA.........................................................................................................................30 4.2 MODELO DE DADOS................................................................................................................................30 4.2.1 Esquema da base de dados.......................................................................................................32 4.2.2 Tabelas......................................................................................................................................33 1. Agentes....................................................................................................................................................33 2. Antecedentes............................................................................................................................................33 3. Protoreg...................................................................................................................................................34 4. proto_agentes...........................................................................................................................................36 5. Proto_ag_ident.........................................................................................................................................37 6. Proto_sintomas.........................................................................................................................................37 7. Proto_antecedentes..................................................................................................................................37 8. Proto_diario.............................................................................................................................................38 9. Proto_diag_base.......................................................................................................................................38 10. Proto_trata..............................................................................................................................................39 11. Proto_rast_comp_sint.............................................................................................................................39 12. Proto_analises........................................................................................................................................40 13. Faixa_etaria............................................................................................................................................40 14. Noticia...................................................................................................................................................41 15. Visitas....................................................................................................................................................42 16. Utilizador...............................................................................................................................................42 4.2.3 Sistema de autenticação............................................................................................................43 4.3 CONCLUSÃO..........................................................................................................................................44 5 LAYOUTSPROTÓTIPOS.....................................................................................................................46 5.1 CONCLUSÃO..........................................................................................................................................48 6 APLICAÇÃO FINAL.............................................................................................................................49 Daniel Nogueira xi
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 6.1 ESTRUTURA DO SITE E FUNCIONAMENTO GERAL...........................................................................................49 6.2 ESTRUTURA DE FICHEIROS.......................................................................................................................52 6.3 FICHEIRO DE CONFIGURAÇÃO...................................................................................................................53 6.4 SISTEMA DE AUTENTICAÇÃO.....................................................................................................................55 6.4.1 Do lado do cliente.....................................................................................................................55 6.4.2 Do lado do servidor..................................................................................................................56 6.5 ADMINISTRAÇÃO....................................................................................................................................57 6.5.1 Importação de dados.................................................................................................................58 6.5.2 Inserir comentários nos registos...............................................................................................59 6.5.3 Tratamento de dados.................................................................................................................60 6.6 CONTADOR DE VISITAS............................................................................................................................69 6.7 ESTATÍSTICAS........................................................................................................................................70 6.7.1 Estrutura da zona de estatística................................................................................................74 6.7.2 Criação dos gráficos.................................................................................................................74 6.7.3 Explicação do código................................................................................................................76 6.8 NOTÍCIAS.............................................................................................................................................81 6.8.1 Inserir notícias..........................................................................................................................84 6.9 REGISTO...............................................................................................................................................91 6.10 CONCLUSÃO........................................................................................................................................98 7 CONCLUSÃO.........................................................................................................................................99 7.1 OBJECTIVOS ATINGIDOS...........................................................................................................................99 7.2 MELHORAMENTOS POSSÍVEIS E TRABALHO FUTURO......................................................................................99 7.3 DIFICULDADES ENCONTRADAS................................................................................................................100 7.4 CONHECIMENTOS ADQUIRIDOS................................................................................................................100 7.5 APRECIAÇÃO FINAL..............................................................................................................................101 8 BIBLIOGRAFIA...................................................................................................................................102 9 ANEXOS................................................................................................................................................104 Daniel Nogueira xii
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Índice de figuras FIGURA 1 - ARQUITECTURA DO PHP [9]...........................................................................................9 FIGURA 2 - CONFIGURAR BIBLIOTECA GD [4].............................................................................11 FIGURA 3 – CONFIGURAR BIBLIOTECA GD [4]............................................................................11 FIGURA 4 – COMPILAR PHP COM GD [4]........................................................................................12 FIGURA 5 – EXEMPLO XML................................................................................................................13 FIGURA 6 – FUNCIONAMENTO CLÁSSICO DE UMA APLICAÇÃO WEB [6]..........................19 FIGURA 7 – FUNCIONAMENTO DE UMA APLICAÇÃO WEB USANDO AJAX [6]..................19 FIGURA 8 – ESQUEMA DA BASE DE DADOS...................................................................................32 FIGURA 9 – DIAGRAMA DE ACTIVIDADE – AUTENTICAÇÃO..................................................44 FIGURA 10 – PRIMEIRA VERSÃO DO LAYOUT PROTÓTIPO DO SITE...................................46 FIGURA 11 – LAYOUT MAQUETA DO SITE COM BASE NA FIGURA 10..................................47 FIGURA 12 – LAYOUT FINAL DO SITE.............................................................................................48 FIGURA 13 – ESTRUTURA DE FICHEIROS......................................................................................52 FIGURA 14 – ZONA DE ADMINISTRAÇÃO.......................................................................................58 FIGURA 15 – FORMATO CSV DOS DADOS RECEBIDOS..............................................................58 FIGURA 16 – POP-UP PARA IMPORTAÇÃO DOS DADOS.............................................................59 FIGURA 17 – INSERIR COMENTÁRIO...............................................................................................60 FIGURA 18 – COMENTÁRIO INSERIDO............................................................................................60 FIGURA 19 – POP-UP PARA EDIÇÃO/INSERÇÃO DE DADOS.....................................................61 FIGURA 20 – INSERÇÃO DE SINTOMAS E ANTECEDENTES.....................................................62 FIGURA 21 – INSERÇÃO DE AGENTES.............................................................................................62 FIGURA 22 – GRÁFICO DE TOTAIS PRESUMÍVEIS......................................................................71 FIGURA 23 – GRÁFICO DE TOTAIS PRESUMÍVEIS POR SEXO.................................................71 FIGURA 24 – GRÁFICO DE TOTAIS PRESUMÍVEIS POR FAIXA ETÁRIA...............................72 FIGURA 25 – GRÁFICOS ENTRE DUAS DATAS..............................................................................72 FIGURA 26 – GRÁFICOS PERSONALIZADOS..................................................................................72 FIGURA 27 – PERSONALIZAÇÃO DE GRÁFICOS..........................................................................73 FIGURA 28 – PRÉ-VISUALIZAÇÃO DOS GRÁFICOS PARA IMPRIMIR...................................74 Daniel Nogueira xiii
    • PROTOREG – Programa piloto de registo de intoxicações alimentares FIGURA 29 – ZONA DE NOTÍCIAS......................................................................................................81 FIGURA 30 – VISUALIZAÇÃO DE UMA NOTÍCIA..........................................................................82 FIGURA 31 – PESQUISANDO POR PALAVRA-CHAVE..................................................................83 FIGURA 32 – ZONA DE INSERÇÃO DE NOTÍCIAS.........................................................................84 FIGURA 33 – POPUP PARA ABRIR NOTÍCIA...................................................................................89 FIGURA 34 – ZONA DE REGISTO.......................................................................................................91 FIGURA 35 – MENSAGEM DE EMAIL JÁ REGISTADO.................................................................92 FIGURA 36 – DIV COM ESTADO DO PEDIDO..................................................................................95 FIGURA 37 – MENSAGEM DE ERRO AO REGISTAR.....................................................................97 FIGURA 38 – MENSAGEM DE SUCESSO DO REGISTO.................................................................97 Daniel Nogueira xiv
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Índice de tabelas TABELA 1 – PLANEAMENTO DO PROJECTO...................................................................................3 TABELA 2 – TABELA AGENTES..........................................................................................................33 TABELA 3 – TABELA AGENTES..........................................................................................................33 TABELA 4 – TABELA PROTOREG......................................................................................................34 TABELA 5 - TABELA PROTO_AGENTES..........................................................................................36 TABELA 6 – TABELA PROTO_AG_IDENT........................................................................................37 TABELA 7 – TABELA PROTO_SINTOMAS.......................................................................................37 TABELA 8 – TABELA PROTO_ANTECEDENTES............................................................................37 TABELA 9 – TABELA PROTO_DIARIO..............................................................................................38 TABELA 10 – TABELA PROTO_DIAG_BASE....................................................................................38 TABELA 11 – TABELA PROTO_TRATA............................................................................................39 TABELA 12 – TABELA PROTO_RAST_COMP_SINT......................................................................39 TABELA 13 – TABELA PROTO_ANALISES......................................................................................40 TABELA 14 – TABELA FAIXA_ETARIA............................................................................................41 TABELA 15 – TABELA NOTICIA.........................................................................................................41 TABELA 16 – TABELA VISITAS...........................................................................................................42 TABELA 17 – TABELA UTILIZADOR.................................................................................................43 TABELA 18 – VIEW TOTAISPRES.......................................................................................................75 TABELA 19 – VIEW PFE_2....................................................................................................................75 TABELA 20 – VIEW SEXOPORDIA.....................................................................................................75 Daniel Nogueira xv
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Índice de extractos de código EXTRACTO 1 – EXEMPLO DE UTILIZAÇÃO DA CLASSE SACK...............................................21 EXTRACTO 2 – ESTRUTURA DO SITE..............................................................................................50 EXTRACTO 3 – FUNÇÃO QUE EFECTUA O PEDIDO DAS PÁGINAS POR AJAX...................51 EXTRACTO 4 – FICHEIRO DE CONFIGURAÇÃO...........................................................................53 EXTRACTO 5 – MÓDULO DE INCLUSÃO DO FICHEIRO DE CONFIGURAÇÃO...................54 EXTRACTO 6 – FUNÇÃO VALIDALOGIN.........................................................................................55 EXTRACTO 7 – VALIDA LOGIN DO LADO DO SERVIDOR.........................................................57 EXTRACTO 8 – FUNÇÃO DOIT............................................................................................................63 EXTRACTO 9 – PRIMEIRA PARTE DO SCRIPT ‘INSERT_SAA.PHP’........................................65 EXTRACTO 10 – SEGUNDA PARTE DO SCRIPT ‘INSERT_SAA.PHP’........................................66 EXTRACTO 11 – RESPOSTA XML (REPETIDO)..............................................................................66 EXTRACTO 12 – RESPOSTA XML (INSERIDO)...............................................................................67 EXTRACTO 13 – RESPOSTA XML (ERRO).......................................................................................67 EXTRACTO 14 – FUNÇÃO EXECUTADA QUANDO O PEDIDO É COMPLETADO.................67 EXTRACTO 15 – PRIMEIRA PARTE DA FUNÇÃO NEWCAMPO................................................68 EXTRACTO 16 – SEGUNDA PARTE DA FUNÇÃO NEWCAMPO.................................................69 EXTRACTO 17 – CHAMADA DA FUNÇÃO INCREMENTA_VISITAS.........................................69 EXTRACTO 18 – FUNÇÃO INCREMENTA_VISITAS......................................................................70 EXTRACTO 19 – INCLUINDO FICHEIROS.......................................................................................76 EXTRACTO 20 – DEFININDO TÍTULOS E NOME DOS MESES...................................................76 EXTRACTO 21 – VERIFICAÇÃO DE VARIÁVEIS...........................................................................77 EXTRACTO 22 – CONTINUAÇÃO DO EXTRACTO ANTERIOR..................................................78 EXTRACTO 23 – CONTINUAÇÃO DO EXTRACTO ANTERIOR..................................................78 EXTRACTO 24 – CONTINUAÇÃO DO EXTRACTO ANTERIOR..................................................79 EXTRACTO 25 – CONTINUAÇÃO DO EXTRACTO ANTERIOR..................................................80 EXTRACTO 26 - FUNÇÃO QUE COMUNICA COM O SERVIDOR PARA TRATAR NOTÍCIAS ......................................................................................................................................................................85 EXTRACTO 27 – EXTRACTO DA VERIFICAÇÃO DA ACÇÃO NO SERVIDOR.......................86 Daniel Nogueira xvi
    • PROTOREG – Programa piloto de registo de intoxicações alimentares EXTRACTO 28 – FUNÇÃO QUE ESCREVE A RESPOSTA XML NO SERVIDOR......................86 EXTRACTO 29 – FUNÇÃO QUE TRATA A RESPOSTA XML RECEBIDA DO SERVIDOR.....87 EXTRACTO 30 – VARIÁVEIS DE CONTROLO.................................................................................87 EXTRACTO 31 – VARIÁVEIS TEMPORÁRIAS DE CONTROLO..................................................88 EXTRACTO 32 – CONTINUAÇÃO DA FUNÇÃO TRATARESPOSTA..........................................88 EXTRACTO 33 – UTILIZANDO A API DO FCKEDITOR................................................................89 EXTRACTO 34 – FUNÇÃO ABRIR.......................................................................................................90 EXTRACTO 35 – FUNÇÃO ABRIR (NO FICHEIRO ABRIR_NOTICIA.JS).................................90 EXTRACTO 36 – RESPOSTA XML DO SERVIDOR.........................................................................90 EXTRACTO 37 – FUNÇÃO PARA VALIDAR EMAIL......................................................................92 EXTRACTO 38 – VARIÁVEIS GLOBAISVARIÁVEIS GLOBAIS..................................................93 EXTRACTO 39 – FUNÇÃO PARA CRIAR O OBJECTO XMLHTTPREQUEST..........................93 EXTRACTO 40 – FUNÇÃO QUE FAZ A COMUNICAÇÃO COM O SERVIDOR........................94 EXTRACTO 41 – FUNÇÃO HANDLEHTTPRESPONSE...................................................................95 EXTRACTO 42 – CÓDIGO NO SERVIDOR QUE VERIFICA SE O EMAIL JÁ ESTÁ REGISTADO..............................................................................................................................................96 EXTRACTO 43 – FUNÇÃO PARA GERAR A PASSWORD..............................................................98 EXTRACTO 44 – GERAR EMAIL A ENVIAR....................................................................................98 EXTRACTO 45 - CLASSE SACK (PARTE 1).....................................................................................105 EXTRACTO 46 - CLASSE SACK (PARTE 2).....................................................................................106 EXTRACTO 47 - CLASSE SACK (PARTE 3).....................................................................................107 EXTRACTO 48 - CLASSE SACK (PARTE 4).....................................................................................108 EXTRACTO 49 - CLASSE SACK (PARTE 5).....................................................................................109 Daniel Nogueira xvii
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 1 Introdução Neste capítulo pode encontrar uma breve apresentação do projecto e da empresa, o enquadramento, os objectivos do trabalho e os resultados previstos. Assim como o planeamento do projecto. 1.1 Enquadramento A Biostrument enquadra-se na área das novas tecnologias, estabelecendo sinergias entre o conhecimento científico académico e as empresas. O principal objectivo da Biostrument é o de desenvolver, propor e implementar soluções tecnologicamente eficazes para problemas reais das empresas. Pretende ser o interlocutor activo entre as empresas e o meio científico, promovendo a rápida e eficaz transferência do know-how adquirido. A Biostrument proporciona o acesso a tecnologias de ponta na implementação e/ou automatização de processos nas áreas da química, bioquímica e biotecnologia e dá apoio científico directo às empresas de modo a optimizar recursos e valorizar os seus índices tecnológicos, colocando-as na vanguarda da tecnologia a nível de mercado europeu. 1.2 Apresentação do projecto/estágio As toxinfecções alimentares são um problema de saúde pública a nível nacional e europeu. Existem várias razões e diversas fontes para os níveis de incidência destas infecções, nomeadamente o incorrecto manuseamento e preparação, acondicionamento, distribuição, etc. dos alimentos ao longo da cadeia alimentar. Os microrganismos causadores de intoxicações alimentares possuem normalmente características muito distintas originando em muitos Daniel Nogueira 1
    • PROTOREG – Programa piloto de registo de intoxicações alimentares dos casos um quadro clínico tipificado mas com consequências muito diversas. A inexistência de um mecanismo de registo sistemático destes casos não permite neste momento elaborar estatísticas nacionais do número de casos e suas consequências dificultando por um lado a elaboração de planos de prevenção e por outro a validação e da eficácia dos mesmos. Para a criação e implementação de sistemas eficazes de higiene e segurança alimentar é fundamental a avaliação dos riscos, nomeadamente riscos de contaminação microbiológica e/ou química. Deste modo, é necessário, que existam estudos que permitam avaliar correctamente os riscos associados aos vários produtos alimentares de forma a criar mecanismos de prevenção adequados que possam ser correctamente implementados. A falta de documentação organizada e tratamento de informação sobre esta matéria, não permite saber qual a dimensão e tipo de toxinfecções alimentares em Portugal, criando um obstáculo à correcta avaliação dos riscos na cadeia alimentar e consequentemente à prevenção. Além disso, dificulta o diagnóstico clínico e a identificação do(s) alimento(s) causador(es) de tais problemas, não permitindo a avaliação do impacto das medidas de prevenção já existentes ou entretanto criadas. 1.2.1 Objectivo Pretende-se com este projecto a criação de um sistema de registo dos casos das toxinfecções alimentares em Hospitais Nacionais que permita efectuar um estudo sistemático e estatístico dos dados. Para tal, será criada: • Uma base de dados para inserção sistemática de todo o processo clínico, salvaguardando o anonimato dos utentes, que permita um tratamento eficaz dos dados; • Ao longo do projecto serão criados modelos estatísticos que permitam não só a identificação da taxa de incidência cada tipo Daniel Nogueira 2
    • PROTOREG – Programa piloto de registo de intoxicações alimentares de toxinfecção mas também a possibilidade de associar sintomas aos diversos tipos de agentes infecciosos e alimentos contaminados. • Um portal de divulgação dos dados através de gráficos estatísticos; • Uma zona de notícias. 1.2.2 Resultados previstos Os resultados deste projecto serão periodicamente publicados num portal específico e dedicado para o efeito que estará disponível para todos os interessados das comunidades científicas. Desenvolver mais o conhecimento real e actualizado das principais fontes de exposição para os humanos ao longo da cadeia alimentar, e o respectivo agente etiológico poderá servir de base para a criação de novas medidas de prevenção, fiscalização e controlo da Segurança Alimentar. 1.2.3 Planeamento de projecto Tarefa Início Fim Análise 13-FEV-2006 24- FEV -2006 Estudo das tecnologias 27- FEV -2006 10-MAR-2006 Implementação 13-MAR-2006 05-MAI-2006 Testes 08-MAI-2006 11-MAI-2006 Relatório 12-MAI-2006 02-JUN-2006 Tabela 1 – Planeamento do projecto • Análise – esta fase compreendeu o estudo do problema e a definição do modelo de dados para dar suporte a toda a informação necessária; • Estudo das tecnologias – esta fase incidiu no estudo das diferentes tecnologias. No caso do PHP e do Ajax recorreu-se a alguns exemplos para compreender o seu funcionamento. Esta Daniel Nogueira 3
    • PROTOREG – Programa piloto de registo de intoxicações alimentares fase prolongou-se também durante a fase de implementação, uma vez que à medida das necessidades eram adquiridos novos conhecimentos; • Implementação – esta fase compreendeu a execução do projecto em si, passando pela elaboração da base de dados, do protótipo até chegar à versão final; • Testes – nesta fase foram efectuados alguns testes para detecção de bugs correcção dos mesmos. • Relatório – nesta fase foi elaborado o relatório do projecto. 1.2.4 Reuniões de acompanhamento Data: 14 de Fevereiro de 2006 Participantes: Eng. Constantino Martins (ISEP), Daniel Nogueira (ISEP), Dr. Luís Meireles (Biostrument) Local: ISEP Temas Debatidos: Apresentação do projecto ao orientador; Apresentação do supervisor de estágio ao orientador; Tecnologias usadas; Conclusão: Nesta reunião ficaram definidas algumas tecnologias que iram ser utilizadas. Ficaram definidos os prazos para a conclusão do projecto. Data: 5 de Abril de 2006 Participantes: Eng. Constantino Martins (ISEP), Daniel Nogueira (ISEP), Dr. Luís Meireles (Biostrument). Local: ISEP Temas Debatidos: Ponto de situação do projecto; Conclusão: Em resumo desta reunião ficaram definidas novas tarefas, e novos métodos de trabalho. Data: 15 de Maio de 2006 Daniel Nogueira 4
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Participantes: Eng. Constantino Martins (ISEP), Daniel Nogueira (ISEP) Local: ISEP Temas Debatidos: Ponto de situação do projecto; Conclusão: Após esta reunião percebeu-se que o tempo disponível para acabar o projecto poderia não ser cumprido. Definiram-se então novos prazos. Data: 6 de Junho de 2006 Participantes: Eng. Constantino Martins (ISEP), Daniel Nogueira (ISEP Local: ISEP Temas Debatidos: Discussão da estrutura do relatório; Conclusão: Ficou definida a estrutura do relatório a realizar. Daniel Nogueira 5
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 2 Tecnologias utilizadas Para o desenvolvimento do projecto, foram utilizadas várias tecnologias escolhidas pela empresa por vários motivos: já eram utilizadas na empresa daí a continuidade na sua utilização, e o aspecto mais importante é que todas as tecnologias usadas são de uso livre. • HTML para definir a estrutura do site; • CSS para definir a apresentação visual do site; • JavaScript para tratamento dinâmico da páginas utilizando HTML DOM, validação de forms e para utilizar o objecto XMLHttpRequest para pedir ou enviar informação ao servidor sem ser necessário actualizar a página completa; • PHP foi utilizado para fazer a ligação ao Sistema de Gestão de Base de Dados (SGBD) e para permitir páginas dinâmicas; • Apache como servidor web; • MySQL foi o SGBD escolhido uma vez que já era utilizado na empresa, é muito rápido para aplicações web; • JPGraph é uma classe que permitiu incluir facilmente gráficos estatísticos no site; • XML teve um papel fundamental, pois foi utilizado para auxiliar a transferência de dados entre o cliente (JavaScript) e o servidor (PHP); • AJAX foi bastante utilizado para fazer a comunicações entre o cliente e o servidor sem ser necessário a actualização completa das páginas. Basicamente este processo resume-se a: o cliente faz um pedido ao servidor por GET ou POST, enquanto a resposta não é recebida o cliente pode ir executando outras tarefas que não dependam da resposta do servidor, por sua vez o servidor processa o pedido e envia a resposta para o cliente em formato XML, ao receber a resposta o cliente analisa o XML recebido e efectua as acções programadas. Daniel Nogueira 6
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 2.1 HTML A linguagem HTML (HyperText Markup Language) é uma linguagem de formatação de documentos, não é uma linguagem de programação, e é composta por tags (etiquetas), tags esses que permitem descrever a estrutura do documento. A linguagem HTML tem por base a linguagem Standard Generalized Markup Language (SGML), linguagem esta que é utilizada para descrever a estrutura geral de vários tipos de documentos. A linguagem HTML é um padrão mantido pelo World Wide Web Consortium (W3C) que integra empresas, universidades e institutos. Os documentos HTML podem conter diferentes tipos de conteúdo como texto, imagem, som e vídeo. Esse conteúdo pode depois ser visualizado por qualquer pessoa que utilize um browser e que esteja a consultar documentos HTML (páginas web) independentemente do tipo de terminal utilizado (computador, pda, telemóvel ou outro). [1] 2.2 CSS Cascading Style Sheets (CSS) ou em português, folhas de estilo, é uma tecnologia que permite ao programador criar graficamente páginas Web de uma maneira muito mais precisa permitindo que os resultados finais sejam praticamente idênticos em qualquer browser com algumas excepções. Com CSS o programador pode manipular margens, tipos de letra, fundos, cores, espaçamento de caracteres, e um sem número de outras propriedades, o objectivo da utilização de folhas de estilo, é separar o estilo do conteúdo da página, do conteúdo em si. Existem duas formas de utilizar folhas de estilo, ou incluindo o código directamente no HTML (definindo os estilos no seu header), ou no caso de já se possuir alguma experiência, esse código pode ser escrito num ficheiro à parte e incluída apenas uma referência (link) para o mesmo no header da página em questão. Daniel Nogueira 7
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Usualmente a cada estilo é atribuído um nome e esse nome é depois usado dentro da tag do elemento na propriedade class. [2] 2.3 JavaScript O JavaScript é uma linguagem de programação criada para dar mais interactividade e maior funcionalidade às páginas da Web. Tendo sido inicialmente desenvolvida pela Netscape, a linguagem JavaScript acabou por dar origem à especificação técnica ECMAScript, que é um padrão oficial reconhecido pela indústria. Apesar de esta linguagem ser mais conhecida pelo nome de JavaScript, e de a versão produzida pela Microsoft ter recebido o nome de JScript, a verdade é que se tratam de implementações que sendo fiéis à norma ECMAScript lhe acrescentaram novas funcionalidades úteis, mas respeitando sempre as especificações oficiais. O código escrito em JavaScript destina-se a ser executado pelo browser quando a página HTML que o contém é visualizada. Ele é uma parte integrante da página e permite que o browser seja capaz de tomar decisões quanto ao modo como o conteúdo é apresentado ao utilizador e como pode ser manipulado. 2.4 PHP O PHP (Hypertext Preprocessor) é uma linguagem de Scripting. Tem este nome porque o código PHP é interpretado e não compilado. Isto quer dizer que, ao contrário de outras linguagens como o C, que o seu código é compilado, e depois executado como um programa normal, o PHP necessita sempre de um "parser" para interpretar o seu código. A sua principal função é a de desenvolver conteúdos web dinâmicos, e foi para essa finalidade que foi criado. [3] Daniel Nogueira 8
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 1 - Arquitectura do PHP [9] O cliente solicita a página a partir do browser ao servidor http. Este verifica que o código html contém embebido um script PHP e chama o módulo PHP para efectuar o processamento. Se no script existirem comandos que abrem uma ligação a uma base de dados, o PHP trata de efectuar essa ligação. Os dados pretendidos são então extraídos da base de dados sendo enviados pelo PHP ao servidor HTTP. O servidor web envia os dados ao browser cliente sendo estes visualizados numa página html devidamente formatada. Deste modo ao visualizarmos no browser o código fonte, apenas veremos HTML, pois o que o servidor enviou foi o output devidamente processado, sendo este o resultado final visível. 2.5 Apache É um software servidor http totalmente gratuito, sendo este o mais usado no mundo (cerca de 68,4% no final de Janeiro de 2005, segundo dados da Netcraft (Netcarft 2005)). Contudo corre em vários sistemas operativos, tais como BSD, GNU/Linux, MacOS e Windows sendo bastante flexível em termos de configuração. Das vantagens que o servidor apresenta salientam-se as seguintes: Daniel Nogueira 9
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • É gratuito, o que permite aos programadores descarregarem-no e adaptarem-no às suas necessidades, sem pagarem por isso; • É modular, facilitando a interligação do servidor Web com outras aplicações ou o acréscimo de funcionalidades ao servidor; • A documentação para configuração e/ou programação está disponível publicamente; • Implementa todas as funcionalidades do HTTP/1.1. 2.6 MYSQL O MySQL é um SGBD relacional, eficiente e optimizada para aplicações Web. Este SGBD é multi-plataforma, sendo compatível com vários sistemas operativos. As tabelas criadas podem atingir o tamanho de 4 GB. O MySQL é compatível com várias linguagens de programação, tais como PHP, C, Java, Visual Basic, entre outros. O MySQL não tem recursos sofisticados, mas para aplicações não muito complexas, ele é uma óptima indicação. O facto de utilizar apenas recursos essenciais (o que atende à maioria das aplicações de base de dados existentes) fez com que sua adopção e consequente suporte fosse grande. Trata-se da base de dados de código livre mais utilizado no mundo. [11] 2.7 JPGRAPH O JPGraph é uma biblioteca para criação de gráficos que tem como base a biblioteca GD do PHP. O JPGRAPH simplifica a criação de gráficos através de scripts PHP. Para adicionar a biblioteca GD ao PHP na plataforma windows basta a alterar no ficheiro php.ini a seguinte linha: [4] Daniel Nogueira 10
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 2 - Configurar biblioteca GD [4] Para descomentar a linha, é só retirar o ; (ponto é vírgula) do início da linha. Figura 3 – Configurar biblioteca GD [4] Em linux terá que fazer download das seguintes bibliotecas: • ftp://ftp.uu.net/graphics/jpeg/ • http://www.libpng.org/pub/png/libpng.html • http://www.freetype.org/ Instale os devidos pacotes e compile o PHP com os seus parâmetros acrescidos dos seguintes comandos: Daniel Nogueira 11
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 4 – Compilar PHP com GD [4] O que está em negrito é o directório de instalação de cada pacote. 2.8 XML Extensible Markup Language (XML) é uma ferramenta extremamente poderosa no que respeita à gestão, organização e visualização de bases de dados textuais. Os principais objectivos do XML são: • Separação do conteúdo e da formatação • Legibilidade tanto por humanos quanto por máquinas • Possibilidade de criação de tags sem limitação • Criação de arquivos para validação de estrutura • Com o seu uso podem-se interligar bases de dados distintas • Simplicidade • XML concentra-se na estrutura da informação e não na sua aparência. [5] Daniel Nogueira 12
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 5 – Exemplo XML 2.9 AJAX Asynchronous JavaScript and XML (Ajax) é uma técnica de desenvolvimento Web para a criação de aplicações bastante interactivas. Para tal Ajax utiliza um conjunto de tecnologias já existentes há algum tempo. • HTML e CSS para a apresentação dos dados. • JavaScript e DOM, de forma a mostrar informação dinamicamente. • XMLHttpRequest como forma de trocar informação com o servidor web de forma assíncrona. O seu nome advém desse conjunto de tecnologias: “Asynchronous JavaScript and XML”. Daniel Nogueira 13
    • PROTOREG – Programa piloto de registo de intoxicações alimentares No capítulo 3 é aprofundado o estudo da tecnologia Ajax, visto que é uma “tecnologia” recente e que não é leccionada no curso de Engenharia informática. Daniel Nogueira 14
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 3 AJAX A utilização de Ajax permite a criação de aplicações web com um comportamento parecido com aplicações que correm em desktop. Numa aplicação web normal o utilizador efectua um pedido ao servidor e fica à espera do resultado. Normalmente é necessário esperar que o servidor responda, que a página faça refresh e que o pedido volte, para gerar uma nova página. Grande parte do tempo o utilizador tem que estar à espera, ou seja, não é tão interactiva como uma aplicação de desktop em que os resultados são obtidos instantaneamente. Do ponto de vista do utilizador não faz sentido que após o carregamento da interface, sempre que interaja com a aplicação web, tenha de ficar à espera que esta comunique com o servidor. Ajax tenta eliminar a diferença em termos de funcionalidades e interactividade que existe entre aplicações web e de desktop, permite que seja possível a utilização de interfaces dinâmicas e formas de interacção mais avançadas. Assim Ajax apresenta uma nova forma de desenvolvimento para os programadores web na qual se conta com as limitações que se pensavam existir, trazendo uma maior gama de possibilidades para a criação de aplicações web. 3.1 Aparecimento do Ajax Não se pode atribuir uma data para o aparecimento da aplicação de Ajax. No entanto o nome foi dado por Jesse James Garrett da Adaptive Path em 18 de Fevereiro de 2005. A primeira técnica de remote scripting assíncrono foi criada pela Microsoft em 1998. Ainda não fazendo uso do objecto XMLHttpRequest, funcionando sobre uma JavaApplet, no entando a Microsoft não aproveitou esta inovação. Mais tarde, por volta 2001/2002, a Netscape através do DevEdge começou a suportar esta tecnologia através de um IFRAME. Daniel Nogueira 15
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Hoje em dia é impossível ler um site qualquer de notícias orientado para tecnologia (como slashdot.org ou digg.com) sem sermos inundados por um número abismal de artigos que referem Ajax, seja de um modo positivo seja de um modo negativo ou apenas de uma maneira imparcial. Apesar de, como já foi referido na anteriormente, esta maneira de desenvolver para a web já exista há algum tempo, apenas nestes últimos meses tem tomado esta proeminência. Isto sucede em grande parte devido à adopção alargada da Google pelo Ajax: podemos ver pedaços em todos os seus produtos web de maior popularidade, seja o caso das sugestões dadas automaticamente e instantaneamente aquando da inserção de caracteres para uma pesquisa dada pelo Google Suggest, ou então pela facilidade da manipulação de mapas (zoom in, zoom out, arrastar) no Goggle Maps, no uso do GMail, a aplicação web que veio revolucionar a maneira como usamos o webmail, com a sua interface simples, eficaz e não intrusiva, e ainda na personalização da homepage do Google, que usa mecanismos de “drag and drop” para manipular os seus conteúdos, apresentada na figura 1. Pode-se dizer então que a Google é a responsável pelo actual buzz que circula em praticamente todo o Silicon Valley, apesar de não ter sido nem o criador de Ajax nem quem primeiro utilizou esse termo para definir o conjunto de técnicas usadas. Mas isto não quer dizer que apenas eles usem Ajax: por todo lado novas empresas começam a usar e ficar curiosas das suas potencialidades, mesmo sem saber muito bem porque é que toda a gente usa, como por exemplo uma empresa que faz software colaborativo, Zimbra, em que o seu CEO quando fundou a empresa apenas pensava que Ajax era um produto de limpeza de casas de banho, mas actualmente juntou 16 milhões de dólares em capital de risco, tudo isto para o desenvolvimento de aplicações que usem Ajax. Mas até a Microsoft actualmente está virada para toda este novo Daniel Nogueira 16
    • PROTOREG – Programa piloto de registo de intoxicações alimentares modo de “fazer a net” como se pode ver pelos seus esforços com a introdução do portal http://www.live.com no aparecimento da sua nova estratégia e de aplicações totalmente web, como por exemplo uma versão do seu muito popular Microsoft Office, sendo esta estratégia “live” parte também do lançamento do seu novo sistema operativo (Windows Vista). Por isso o que se pode ver hoje em dia é não só o uso de Ajax como, digamos, um brinquedo dos programadores, como foi usado pela Google no inicio, mas a tornar- se uma opção completamente viável, usável, uma moda que toda a gente quer usar, que ninguém quer perder. Claro que todo este falatório à sua volta e toda esta ânsia de uso leva a todos os exageros. A tentativa de incorporar Ajax em todas as páginas em todo lado seja para o que for leva a que existam muitos detractores do seu uso, indicando que apenas dificulta a fluidez. Nesta altura observa-se uma luta acesa entre aqueles que valorizam Ajax indicando praticamente como a nova ordem na web e aqueles que vêm apenas Ajax como uma moda algo para não ser levado a sério que apenas traz coisas negativas a toda a experiência de uso da Internet. Qual destes dois terá razão apenas o tempo dirã, mas o rumo actual leva a pensar que apesar de ser uma moda e de ter tomado a Internet de assalto, Ajax está para ficar e cada vez mais a ser objecto de estudo e de uso não apenas por aqueles que acham interessante e querem experimentar mas também cada vez maiores e mais importantes empresas: Microsoft, Google e até a Yahoo! com a sua aquisição, por exemplo, do Flickr que usa Ajax. Inclusive, através de publicações de tutoriais por parte de pessoas com provas dadas no mundo sancionadas por essas empresas, sendo um dos últimos exemplos um artigo publicado no site da IBM da autoria de Brett McLaughlin, autor e editor pertencente à bem conhecida O’Reilly and Associates, intitulado “Mastering Ajax, Part 1: Introduction to Ajax, Daniel Nogueira 17
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Understanding Ajax, a productive approach to building Web sites, and how it works”. Tudo isto inerente à revolução que muitos chamam de Web 2.0 que está a caminho. 3.2 Tecnologias base Ajax não é uma tecnologia. Ajax é um modelo para aplicações web composto por várias tecnologias que se ligaram para o criar. Essas tecnologias são: • HTML Para a apresentação das páginas no browser. • DOM (Document Object Model) Permite aceder e manipular os elementos XML DOM para tratar a resposta que vem do servidor, e os elementos do HTML DOM para manipular a página dinamicamente. • XML XML é o meio de transporte dos dados no sentido servidor-cliente. Os dados são encapsulados em tags XML, de modo a que sejam extraídos e tratados pelo cliente quando os recebe. • XMLHttpRequest Para receber dados assincronamente, o XMLHttpRequest permite ao JavaScript fazer pedidos HTTP ao servidor remoto sem ser necessário recarregar a página. • JavaScript JavaScript é a linguagem que vai ser usada para construir um motor que coordena e controla toda a aplicação do lado do cliente, que faz o XMLHttpRequest, que recebe o XML do servidor e que é responsável pela actualização da página para o cliente, bem como da sua interactividade. Daniel Nogueira 18
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 3.3 Funcionamento clássico de uma aplicação web Figura 6 – Funcionamento clássico de uma aplicação web [6] No modelo clássico a interface está no browser do cliente: este lança um HTTP Request para o servidor, que processa e retorna o HTML e CSS correspondentes. 3.4 Funcionamento de uma aplicação web usando Ajax Figura 7 – Funcionamento de uma aplicação web usando Ajax [6] Daniel Nogueira 19
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Com Ajax a interface em vez de lançar um HTTP Request lança uma chamada de JavaScript para uma aplicação Ajax que se encontra do lado do cliente. Esta por sua vez lança o HTTPRequest para o servidor que trata do pedido e retorna os dados correspondentes para a aplicação Ajax, que por fim os mostra ao utilizador. A grande diferença entre estes dois modelos é que enquanto que no clássico é necessário recarregar toda a página de cada vez que é feito um pedido, com Ajax não, uma vez que depois do carregamento inicial só se vão alterando os dados na área onde estes vão ser colocados de cada vez que é feito um pedido. O facto de ser assíncrono também permite que se continue a processar outros dados enquanto se espera pela resposta do servidor. 3.5 Classe Sack A “espinha dorsal” de Ajax é o XMLHttpRequest e a maneira como a aplicação em JavaScript é construída. Para simplificar o uso de Ajax foi usada uma classe JavaScript (anexo 1). Breve explicação da utilização da classe sack: Daniel Nogueira 20
    • PROTOREG – Programa piloto de registo de intoxicações alimentares var ajax = new sack(); //instancia um objecto da classe sack ajax.element = "div"; //define o elemento onde vai ser //exibida aa interacção do cliente com //o servidor ajax.requestFile = "page.php"; //URL da página no servidor ajax.setVar("var",variavel); //define as variáveis ajax.method = "POST";//define metodo do pedido http ‘GET’ ou‘POST’ ajax.onLoading = function whenLoading(){ //quando está a enviar os dados ajax.element.innerHTML = "Sending Data..."; }; ajax.onLoaded = function whenLoaded(){ //quando os dados são recebidos no servidor ajax.element.innerHTML = "Data Sent..."; }; ajax.onInteractive = function whenInteractive(){ //quando os dados estão a ser recebidos ajax.element.innerHTML = "Getting data..."; }; ajax.onCompletion = function(){ //quando os dados sao recebidos totalmente no cliente ajax.element.innerHTML = "Finished..."; }; ajax.runAJAX(); Extracto 1 – Exemplo de utilização da classe Sack Inicialmente é instanciado um objecto da classe ‘sack’, depois definem-se as variáveis internas: • ajax.element é o elemento onde vai aparecer a informação sobre o estado do pedido, que permite ao utilizador saber que está a haver interacção. • ajax.requestFile é o URL do script do lado do servidor que vai ser chamado, se for utilizado o método ‘GET’ as variáveis podem ser passadas explicitamente no URL. • ajax.method é o método do pedido http, que pode ser “GET” ou “POST”. Daniel Nogueira 21
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • ajax.onLoading é a função que é chamada quando os dados estão a ser enviados para o servidor; • ajax.onLoaded é chamada quando os dados foram completamente enviados; • ajax.onInteractive é executada quando os dados estão a ser recebidos pelo cliente; • ajax.onCompletion é a função que é chamada quando a resposta foi totalmente recebida pelo cliente. Quando a resposta chega o cliente trata os dados recebidos. 3.6 Vantagens e desvantagens Como acontece com a maioria das tecnologias, o seu sucesso depende do uso que as pessoas lhes dão. Indiscutivelmente, usar Ajax levanta algumas questões, tanto para os programadores web como para os utilizadores, que podem pôr em causa o seu uso, mas quando usado correctamente, existem diversas vantagens que não podem ser ignoradas por quem desenvolve aplicações web, como o demonstram os grandes sucessos que se têm observado nos últimos anos como é o caso do GMail da Google. As opiniões divergem neste assunto, sendo que se podem definir claramente dois pólos: os “idealistas”, que tendem a levar mais em conta os aspectos que se prendem com a arquitectura dos sites e as questões tecnológicas subjacentes, e os “pragmáticos” que colocam a experiência que o utilizador tem ao visitar um site no topo das suas prioridades, independentemente do que isso representa para quem desenvolve o site. • Vantagens As principais vantagens decorrentes do uso de Ajax são as observáveis pelos utilizadores dos respectivos sites. Do ponto de vista de quem desenvolve um site as vantagens não são tão óbvias (não se pode dizer que o seu desenvolvimento ou manipulação de dados seja Daniel Nogueira 22
    • PROTOREG – Programa piloto de registo de intoxicações alimentares necessariamente mais simples), contudo estas não deixam de existir, principalmente se se considerar que o uso de Ajax pode alterar a forma como questões de usabilidade serão abordadas no futuro. • Usabilidade As vantagens mais visíveis para um utilizador de um site que use Ajax são as que dizem respeito à sua interactividade e usabilidade. O ganho na interactividade faz com que o comportamento das aplicações web se aproxime do das aplicações de desktop, possibilitando acções como “drag and drop” e dando no geral uma maior fluidez à navegação entre diferentes páginas de um mesmo site. Alguns dos aspectos que mais se destacam a nível da interactividade que Ajax possibilita são: • Tempos de espera mais curtos Não sendo necessário carregar toda a página novamente, há uma grande redução na largura de banda gasta quando se compara um pedido Ajax com um pedido HTTP feito pelo browser para abrir uma página. Menor gasto de largura de banda implica tempos de espera inferiores, o que é vantajoso para qualquer website uma vez que não provoca tantas quebras no acesso à informação. • Validações automáticas na submissão de formulários Esta questão coloca-se especialmente para formulários longos e que requerem validação de diversos campos. Através de Ajax não é necessário esperar que a submissão do formulário termine para saber se um dado username está disponível, ou ter de esperar que uma nova página abra para ver todos os campos do formulário quando parte destes depende do input do utilizador. Daniel Nogueira 23
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • Completação automática de campos Ao preencher campos de texto é frequente que os dados que o utilizador vai inserir sejam previsíveis, quer seja por outro utilizador já os ter inserido (como é o caso de queries repetidas em motores de busca) quer seja por estarem directamente associados ao utilizador em questão (por exemplo no preenchimento automático do campo “endereço” em aplicações de webmail usando o livro de endereço do utilizador). Neste tipo de campos faz sentido usar Ajax para ir buscar dinamicamente as entradas mais frequentes começadas pelas letras que o utilizador já escreveu, reduzindo assim o tempo necessário para escrever entradas de texto longas e eventualmente ajudando o utilizador a escrever aquilo que pretende quando este não sabe exactamente o que escrever (quer seja um endereço de e-mail ou uma palavra-chave de uma pesquisa). • Manipulação de dados altamente interactiva Quando se pretende executar acções como reordenar uma lista de resultados ou até fazer qualquer tipo de filtragem pode valer a pena usar Ajax para não ter de carregar a página novamente. Este tipo de situação aplica-se a todos os acessos a dados que dependem fortemente do input do utilizador. • Navegação em estruturas em árvore profundas Por vezes não é viável carregar todos os dados relacionados com o assunto de uma dada página, sendo informação adicional remetida para nós mais profundos da vista da árvore que está a ser apresentada. Um exemplo desta situação é nos tópicos de alguns foros nos quais as respostas estão encadeadas (isto é, é possível responder a uma resposta de outro utilizador dentro de um tópico), sendo que não é viável mostrar toda a árvore de respostas (mostrando-se apenas um nível da árvore de cada vez). Nestas situações é vantajoso usar Ajax para expandir um nó da árvore, por Daniel Nogueira 24
    • PROTOREG – Programa piloto de registo de intoxicações alimentares oposição a abrir uma página nova com o conteúdo (respostas) desse nó. • Interacção do utilizador com o site Acções como votar em um inquérito (e ver imediatamente os totais da votação) ou colocar uma questão através de um formulário online ganham uma dimensão completamente diferente quando a resposta do site é imediata. O uso de Ajax neste tipo de acções encoraja os utilizadores a darem feedback ao site, o que promove a aproximação utilizador-site e leva os detentores do site a adequarem-se melhor às necessidades dos seus utilizadores. • Desempenho e compatibilidade Os ganhos em usabilidade de Ajax são muitos, mas convém não esquecer que já era possível ter elevados índices de interactividade recorrendo a outras tecnologias. O uso de applets Java ou de elementos Flash em sites não é uma novidade e já era possível através destes melhorar a experiência que o utilizador tem ao visitar um site, porém há dois aspectos a ter em conta neste tipo de elementos: por um lado, trata-se de elementos que computacionalmente são, por vezes, muito pesados para um computador processar, limitando assim o número de utilizadores que conseguem tirar proveito do seu uso; por outro lado, estes elementos requerem frequentemente a instalação de software adicional no computador do utilizador, que muitas vezes não é desejável (tempo necessário para descarregar o software e espaço que ocupa, entre outros). Com Ajax estas questões não são tão importantes, uma vez que cerca de 80% dos sistemas já suportam todos os elementos necessários para a visualização de um site em Ajax sem qualquer tipo de software adicional. Daniel Nogueira 25
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • Desvantagens Ajax não deixa de ter as suas desvantagens [8]. A maioria destas podem ser contornadas pelos programadores web, mas por um lado poucas pessoas têm estes cuidados e por outro tratam-se, de facto, de “truques” para contornar estas dificuldades. Parte destas desvantagens devem-se também ao facto de Ajax ser usado em contextos em que não é adequado: o melhor contexto para usar estas tecnologias é em aplicações web e não em “páginas web”. • Usabilidade Navegar em sites que usem Ajax pode tornar-se um pesadelo quando se pretende executar acções como usar o botão Back ou mostrar o conteúdo que estamos a observar a outra pessoa. Apesar de haver implementações que permitem criar um endereço (URI) que identifica univocamente o recurso que está a ser acedido, como é o caso do Google Maps, a maioria das aplicações não tem esse cuidado. Outra questão que se prende com a navegação entre páginas é o facto de não ser dado feedback ao utilizador sobre o estado dos seus pedidos, isto é, se a página a que o utilizador pretende aceder está efectivamente a ser aberta. Para além disto, há a questão do scrolling: numa página longa em que seja necessário descer o scroller da página para ver um determinado conteúdo, caso o motor Ajax retire um parágrafo acima do conteúdo que está a ser visto todo o texto será “puxado” para cima. Os novos paradigmas de usabilidade possibilitados por Ajax são, por si só, fonte de discórdia. Ainda que existam novas possibilidades a nível de interface, os programadores web devem ter o cuidado de não romper completamente com as convenções existentes uma vez que correm o risco de os utilizadores não saberem como usar os seus sites. Outro aspecto que é negligenciado é o facto de em Ajax haver a necessidade de fazer constantemente pedidos ao servidor para Daniel Nogueira 26
    • PROTOREG – Programa piloto de registo de intoxicações alimentares aceder às páginas. Isto torna-se um problema para pessoas com fracas condições de conectividade e para as quais o uso de cache é importante. Há ainda a ter em conta o facto de que a indexação dos conteúdos por parte de motores de busca não é possível nos conteúdos que são acedidos através de Ajax. Para estes casos seria necessário disponibilizar uma versão acessível sem usar Ajax. Por fim, há ainda a considerar a possibilidade de o browser da máquina do cliente não suportar JavaScript. De acordo com o W3C, cerca de 11% dos utilizadores da web usam browsers que não suportam JavaScript, pelo que têm de se contentar com as versões sem JavaScript que existam ou, no caso de os programadores web não criarem estas versões, simplesmente não podem utilizar o site. • Implementação Relativamente à implementação, há vários aspectos que sofrem com o uso de Ajax. Por um lado, uma vez que depende da máquina do cliente é necessário ter um maior cuidado a nível de testes para garantir que os sites funcionam em todos os sistemas e browsers a que o site se destina. Por outro, uma vez que os sites ficam muito dependentes da comunicação com o servidor para aceder a conteúdos e esta é feita de modo assíncrono é necessário ter cuidados redobrados em termos de segurança, algo que a generalidade dos programadores web não têm. Há ainda uma questão mais prezada pelos “idealistas” de desenvolvimento web que se refere à arquitectura dos sites. Idealmente, o modelo cliente-servidor deveria ser adoptado porém usando Ajax passa-se alguma da lógica da aplicação web para o HTML queé retornado para o cliente. Para além de revelar algum do processamento de dados ao utilizador, que pode não ser desejável, Daniel Nogueira 27
    • PROTOREG – Programa piloto de registo de intoxicações alimentares depende-se da capacidade dos browsers do cliente para processar os dados retornados pelo utilizador e mostrá-los convenientemente. Por fim, a actualização de conteúdos com Ajax pode levar a inconsistências se não houver um tratamento adequado: caso se esteja a ler uma primeira página de um documento, por exemplo, ao actualizar o conteúdo com outras páginas pode ser preciso actualizar também o título da página (no head) e alguns headers, entre outros. • Dispositivos Móveis Uma outra aplicação de Ajax que já começa a surgir é a que diz respeito ao seu uso em dispositivos móveis. Para além das questões de usabilidade, há a considerar nestes dispositivos o ganho em termos de consumo de tráfego, já que em dispositivos móveis esta questão se coloca em duas vertentes: tempo de arregamento e custos associados. Recentemente, os developers do browser Opera lançaram um toolkit que permite lidar com este tipo de pedidos de uma forma mais transparente, de modo a que não seja necessário desenvolver sites específicos para determinados sistemas operativos, como actualmente sucede. Este toolkit traz ainda grandes benefícios no desenvolvimento de interfaces para smart phones e uma vez que a tecnologia Ajax está apenas agora a ganhar notoriedade é provável que venha a surgir maior suporte para este tipo de dispositivos [7]. 3.7 Conclusão Ajax é uma técnica bastante poderosa para o desenvolvimento de aplicações web. No entando tem que se ter cuidado com a sua utilização pois um mau uso desta técnica pode criar aplicações difíceis de utilizar e inseguras. Ultimamente cada vez mais empresas utilizam Ajax para a criação de projectos, de dia para dia esse número aumenta, Ajax pode ser considerado uma moda, mas esta moda está para ficar. Actualmente está a ter um papel muito importante na evolução das aplicações web, sendo impossível ignorar o efeito Daniel Nogueira 28
    • PROTOREG – Programa piloto de registo de intoxicações alimentares dessas aplicações sobre a world wide web e da maneira como a entendemos. Hoje em dia é mais que um repositório de páginas soltas com informação associada: é uma comunidade emergente sendo considerada na actualidade, mais que um luxo, uma necessidade. Move ainda as direcções das grandes empresas, não havendo maior que a Microsoft, estando a focar-se nesta nova ”web social”muitas vezes também chamada de Web 2.0. Como vertiginoso aumento da sua utilização verifica-se neste momento uma grande discussão na comunidade de programadores web sobre as suas vantagens e desvantagens, se deve ser usado ou não. Técnicas como Ajax já existem há alguns anos e nunca vingaram nem perduraram, porque passou-se a centralizar todo o desenvolvimento em tecnologias server-side em detrimento de uma arquitectura mais client-side. As vozes críticas são bastantes devido a várias desvantagens que apresenta o seu mau uso e principalmente da forma como corta com arquitecturas base de HTTP request e resposta de HTML e CSS, em que toda a lógica está do lado do servidor. No entanto todas as vantagens em termos de fluidez e percepção para o utilizador da aplicação, bem como da rapidez de resposta, tornam aliciante o seu uso. Por isso, e como em qualquer tecnologia, não é só por si que é determinado se vale a pena ou não o seu uso, mas sim a forma como se faz esse uso, por isso Ajax sendo usada nas situações correctas pode verificar-se muito vantajosa, por outro lado quando usada de uma maneira errada, a experiência de uso fica completamente destruída. Usando uma analogia com um tema bem conhecido de todos os interessados em ficção-científica (Star Wars): “Ajax seems to be like Darth Vader... Powerful, yet dangerous”. Daniel Nogueira 29
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 4 Análise e estrutura de dados Neste capítulo pretende-se descrever o processo de análise feito bem como a descrição da estrutura de dados que suporta o site desenvolvido. Serão apresentados todos os requisitos funcionais da aplicação. 4.1 Requisitos do sistema Nesta secção serão apresentados os requisitos funcionais do site e dos utilizadores. Os requisitos funcionais do site são a criação de uma zona de administração para importação e tratamento de dados, uma zona de publicação de dados com gráficos estatísticos e uma zona de inserção e publicação de notícias; O administrador tem acesso zonas cruciais do site que são elas a zona de importação de dados, a zona de tratamento dos dados e a zona de inserir notícias. O utilizador registado poderá visualizar a zona de publicação dos dados, e à zona de notícias. O utilizador não registado poderá se registar para ter outro nível de acesso, e visualizar informações básicas no site como consultar os contactos e ler uma introdução sobre o tema do site. 4.2 Modelo de dados A base de dados foi desenvolvida com base numa lista de requisitos elaborado pela empresa [Anexo 2], e teria que suportar toda a informação pretendida. Teria também que permitir o registo de utilizadores e a criação de uma zona de notícias. Daniel Nogueira 30
    • PROTOREG – Programa piloto de registo de intoxicações alimentares O tipo de tabelas do MySQL aconselhado a usar pelo supervisor de estágio foi MyISAM, uma vez que o seu uso não implica custos. Como este tipo de tabelas não suporta chaves estrangeiras, logo é na camada de programação que são efectuadas as validações necessárias para garantir a integridade dos dados. Daniel Nogueira 31
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 4.2.1 Esquema da base de dados Figura 8 – Esquema da base de dados Como se pode visualizar nesta figura a tabela principal é a tabela protoreg, que faz a ligação entre todas as outras tabelas através do atributo id_proto, que é o código do registo de cada caso. Daniel Nogueira 32
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 4.2.2 Tabelas Com este sub-capítulo, pretende-se descrever cada tabela, bem como salientar alguns aspectos importantes em cada uma delas. Para isso será usado uma espécie de Dicionário de Dados em forma de tabela. 1. Agentes Campo Tipo de Dados Comentário id Int(3) Código do agente agente varchar(255) Nome do agente tipo tinyint(1) Tipo de agente Tabela 2 – Tabela Agentes A tabela agentes guarda a informação sobre os diferentes agentes. O campo id e chave primária, e auto_increment como a maior parte dos identificadores das tabelas que se seguem, o que significa que a cada registo inserido o valor do campo id é incrementado automaticamente. O atributo tipo pode assumir três valores: • 1 – Vírus; • 2 – Bactérias; • 3 – Protozoários 2. Antecedentes Campo Tipo de Dados Comentário id Int(3) Código do antecedente antecedente varchar(255) Descrição do antecedente Tabela 3 – Tabela Agentes Foi criada esta tabela para guardar os diferentes tipos de antecedentes, pois já estavam definidos a partida vários tipos de antecedentes. Sendo assim evita-se a repetição de dados. Daniel Nogueira 33
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 3. Protoreg Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo dta_admissao date Data do registo idade tinyint(2) Idade do doente sexo varchar(9) Sexo do doente distrito varchar(50) Distrito do doente diag text Diagnóstico provável confirma bool Se o diagnóstico é confirmado comentario text Permite inserir um comentário estado bool Se o registo já foi revisto ou nao base_diag varchar(255) Diagnóstico com base em alta bool Se o doente teve alta inicio_sintomat varchar(255) Inicio da sintomatologia evo_cli varchar(255) Evolução clínica alimento varchar(255) Alimentos suspeitos analisado bool Se o caso foi analisado Quantos dias antes da consulta foi dias_antes tinyint(2) ingerido o alimento local_ingestao varchar(255) Local de ingestão do alimento Se outras pessoas apresentaram a outras_pessoas bool mesma sintomatologia is_diag_reg_med Se o diagnostico foi registado pelo bool ico médico diag_reg_medico varchar(255) Se foi registado pelo médico qual foi Tabela 4 – Tabela Protoreg Daniel Nogueira 34
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Esta é a tabela principal, é nela que é guardada toda a informação sobre cada registo de cada possível intoxicação alimentar. A chave primária é o atributo id_proto. A seguir é apresentada uma descrição mais detalhada de todos os campos desta tabela e em alguns casos os possíveis valores que podem tomar: • id_proto – este é um campo de controlo do número de registo. A cada registo é incrementado; • dta_admissao – data em que a possível intoxicação alimentar foi registada no hospital; • idade – idade do paciente; • sexo – sexo do paciente; • distrito – distrito do paciente; • diag – diagnóstico feito ao paciente na triagem do hospital; • confirma o 0 – caso de intoxicação não confirmado; o 1 – caso de intoxicação confirmado; • comentário – este campo permite ao administrador inserir um comentário acerca do registo actual aquando da revisão do registo no sistema de administração. • estado o 0 – o registo ainda não foi completamente tratado pela administração; o 1 – o registo foi tratado e está pronto para ser publicado; • base_diag – indica no que se baseou o diagnóstico • alta o 0 – o doente não teve alta na altura que se deslocou ao hospital, ficando internado; o 1 – o doente teve alta; Daniel Nogueira 35
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • inicio_sintomat – quando se registou o inicio dos sintomas, este campo aceita texto; • evo_cli – guarda um pequeno texto com a descrição da evolução clínica do paciente; • alimento – pode ser um só alimento ou então vários, até um máximo de 255 caracteres. • analisado o 0 – indica que o alimento não foi analisado; o 1 – indica que o alimento foi analisado; • dias_antes – número de dias que passaram desde a data de ingestão do alimento suspeito e a data do aparecimento dos sintomas; • local_ingestao – o local onde o alimento foi ingerido; • outras_pessoas o 0 – indica que não houveram outras pessoas a apresentar a mesma sintomatologia; o 1 – indica que outras pessoas que comeram o mesmo alimento apresentaram a mesma sintomatologia; • is_diag_reg_medico o 0 – o diagnóstico não foi registado pelo médico; o 1 – o diagnóstico foi registado pelo médico; • diag_reg_medico – se o diagnóstico foi registado pelo médico este campo guarda um pequeno texto com a sua descrição; 4. proto_agentes Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo na tabela protoreg id_agente int(3) Código do agente Tabela 5 - Tabela proto_agentes Daniel Nogueira 36
    • PROTOREG – Programa piloto de registo de intoxicações alimentares A tabela proto_agentes é uma tabela de relacionamento entre a tabela agentes e a tabela protoreg. Serve para registar os agentes possíveis em cada caso. Os dois campos em conjunto definem a chave primária. 5. Proto_ag_ident Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo na tabela protoreg id_agente int(3) Código do agente Tabela 6 – Tabela proto_ag_ident A tabela proto_ag_ident é uma tabela de relacionamento entre a tabela agentes e a tabela protoreg. É nela que se registam todos os agentes identificados. A chave primária é composta pelos dois atributos. 6. Proto_sintomas Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo na tabela protoreg id_agente int(3) Código do sintoma Tabela 7 – Tabela proto_sintomas A tabela proto_sintomas relaciona as tabelas protoreg e sintomas. Cada caso registado pode ter vários sintomas associados. A chave primária é composta pelos dois campos. 7. Proto_antecedentes Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo na tabela protoreg id_antecedente int(3) Código do antecedente Tabela 8 – Tabela proto_antecedentes Daniel Nogueira 37
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Esta tabela armazena todas as relações entre um caso registado na tabela protoreg e um ou mais antecedentes. A chave primária é composta pelos dois campos. 8. Proto_diario Campo Tipo de Dados Comentário id bigint(11) Código do diário id_proto bigint(11) Código do registo na tabela protoreg diario longtext Texto com a descrição completa do diário Tabela 9 – Tabela proto_diario A cada registo da tabela protoreg pode corresponder um ou mais diários, por isso, para além do id_proto (código do registo na tabela protoreg) é usado o campo id (código da tabela proto_diario) como chave que é um auto_increment. 9. Proto_diag_base Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo na tabela protoreg sintomas bool Código do antecedente diag_clinico boll Se o diagnóstico foi feito pelo médico Se o diagnóstico teve como base anal_gerais bool análises gerais Se teve como base análises anal_micro boll microbiológicas outra bool Se teve base noutro método p_analisado varchar(255) Produto analisado outro varchar(255) Descrição de outro método Tabela 10 – Tabela proto_diag_base Daniel Nogueira 38
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Está tabela armazena a informação relativa ao método no qual foi baseado o diagnóstico. Se foi com base em sintomas, se foi diagnóstico clínico, com base em análises gerais, com base em análises microbiológicas, ou outra. Se teve como base analise microbiológicas o campo p_analisado diz-nos qual foi o produto analisado. Cada registo pode ter por base todos os métodos. 10.Proto_trata Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo na tabela protoreg a_biotico bool Se o tratamento é à base de antibiótico tratamento longtext Texto com a descrição do tratamento Tabela 11 – Tabela proto_trata A cada registo desta tabela corresponde um registo da tabela protoreg relacionado pelo atributo id_proto. Aqui é guardada a informação relativa ao tratamento de cada caso, se esse tratamento foi à base de antibióticos o a_biotico tem o valor 1 e o atributo tratamento guardará qual ou quais os antibióticos administrados. Caso contrário o campo a_biotico estará a 0 (zero) e o campo tratamento guardará a descrição do tratamento. 11.Proto_rast_comp_sint Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo na tabela protoreg Se o rastreio é compatível com os compativel bool sintomas Texto com um comentário se não é comentario longtext compatível Tabela 12 – Tabela proto_rast_comp_sint Daniel Nogueira 39
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Esta tabela indica para cada caso se o rastreio é compatível com os sintomas. No caso de não ser compatível o campo comentario permite guardar um pequeno comentário. 12.Proto_analises Campo Tipo de Dados Comentário id_proto bigint(11) Código do registo na tabela protoreg p_medico bool Se as analises foram pedidas pelo médico p_hospital boll Se as analises foram pedidas pelo hospital estado bool Se as analises pedidas estão prontas diag_conf bool Se as analises confirmaram o diagnostico geral bool Se foram pedidas analises gerais micro bool Se foram pedidas analises microbiológicas outra bool Se foi pedido outro método outra_txt varchar(255) Descrição do outro método pedido Tabela 13 – Tabela proto_analises Esta tabela engloba toda a informação necessária acerca dos pedidos de análises. Se as análises foram pedidas pelo médico na altura da consulta podem neste caso ser pedidas ao hospital, o estado desse pedido será guardado no campo estado que ficará com o valor 0 (zero) se o pedido ainda não está completo, caso contrário terá o valor 1. 13.Faixa_etaria Campo Tipo de Dados Comentário id int(1) Código da faixa etária idade_i int(3) Idade inicial Daniel Nogueira 40
    • PROTOREG – Programa piloto de registo de intoxicações alimentares idade_f int(3) Idade final Tabela 14 – Tabela faixa_etaria Esta tabela foi criada para definir as faixas. Estão predefinidas 5 faixas etárias a partida: • 0–5 • 6 - 15 • 16 -30 • 31 – 65 • 66 – 100 Em qualquer altura podem-se alterar os intervalos, assim não implica ter que se alterar o código programado. 14.Noticia Campo Tipo de Dados Comentário id bigint(11) Código da noticia titulo Varchar(255) Titulo da noticia texto text Texto da noticia data datetime Data de criação da noticia apagada bool Se a noticia está “apagada” publicar bool Se a noticia pode ser publicada Tabela 15 – Tabela noticia A tabela noticia armazena todas as noticias inseridas e que poderam estar publicadas no site ou não, dependendo do estado do campo publicar. Se o campo ‘apagada’ estiver a 1 a noticia é considerada como apagada, podendo sempre ser recuperada. Daniel Nogueira 41
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 15.Visitas Campo Tipo de Dados Comentário nvisitas bigint(11) Numero total de visitas do site uvisita datetime Data da ultima visita feita ao site Tabela 16 – Tabela visitas A tabela visitas é usada para controlar o número de visitas ao site e a data da última visita. 16.Utilizador Campo Tipo de Dados Comentário id_utilizador int(5) Identificador único de utilizador tipo varchar(10) Tipo de utilizador nome varchar(255) Nome do utilizador apelidos varchar(255) Apelidos morada varchar(255) Morada cod_postal int(4) Código postal cod_postal2 int(3) Código postal 2 cidade varchar(255) Cidade telefone int(9) Telefone sEmail varchar(255) Email do utilizador profissao varchar(255) Profissão empresa varchar(255) Empresa cargo varchar(255) Cargo que ocupa na empresa sPassword varchar(255) Passord de acesso ao site visitas int(11) Numero de visitas do utilizador Data do ultimo login que o utilizador ultimo_login datetime efectuou Daniel Nogueira 42
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Tabela 17 – Tabela utilizador A tabela utilizador contém campos para armazenar a informação pessoal de cada utilizador. Explicação de alguns campos: • cod_postal e cod_postal2 – Ex: para o código postal 4000-123, cod_postal será 4000 e cod_postal será 123; • sEmail – é o email do utilizador para onde será enviada a palavra passe de acesso ao site. E servirá também para efectuar a autenticação juntamente com a palavra passe. • sPassword – é a palavra passe de acesso ao site, está passe é encriptada com o algoritmo MD5 e ninguém excepto o utilizador terá acesso a ela. • visitas – é o número total de visitas, ou de autenticações que o utilizador efectuar no site. • ultimo_login – é a data da ultima autenticação. 4.2.3 Sistema de autenticação O sistema de autenticação existe em quase todos as e aplicações. O seu objectivo é diferenciar o acesso às diferentes partes do site. Neste caso a autenticação é feita do seguinte modo: • O utilizador acede pelo seu browser ao endereço do site; • Introduz o email e a palavra passe; • Caso os dados estejam incorrectos aparece uma mensagem de erro; • Caso contrário o utilizador é autenticado e tem acesso as funcionalidades de acordo com o seu nível de permissões; • Quando o utilizador faz logout deixa de estar autenticado e só pode aceder às informações mínimas no site. Daniel Nogueira 43
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 9 – Diagrama de actividade – autenticação Para as outras funcionalidades não se revelou necessário este tipo de análise. 4.3 Conclusão Este capítulo deu a conhecer a arquitectura física e lógica dos dados. O dicionário lógico de dados apresentou uma descrição detalhada de cada tabela da BD. A análise do projecto foi composta pelo levantamento dos requisitos e pelo dicionário de dados. Existem dois tipos de requisitos, os funcionais e os não funcionais. Os funcionais foram apresentados sob a perspectiva de cada perfil de Daniel Nogueira 44
    • PROTOREG – Programa piloto de registo de intoxicações alimentares utilizador. A gestão dos requisitos é importante para o sucesso de uma aplicação. Daniel Nogueira 45
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 5 LayoutsProtótipos O aspecto gráfico do site foi sendo alterado ao longo do tempo. Inicialmente o design era muito simples e foi feito mais com o objectivo de poder ver alguma interactividade e para testar as funcionalidades implementadas. Foi-me dito para utilizar tons azuis, então o resultado foi este (Figura 10). Figura 10 – Primeira versão do layout protótipo do site Este não era definitivamente um design atractivo, e era necessário fazer alterações. Falou-se então com o designer que nos deu uma ajudinha no aspecto visual baseando-se no modelo anterior e ainda desenhou um logótipo. O resultado foi o foi o seguinte (Figura 11). Daniel Nogueira 46
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 11 – Layout Maqueta do site com base na Figura 10 Nesta altura era necessário alterar toda a estrutura do site, ou seja, montar o novo esqueleto da página. Foram usadas tabelas para conseguir implementar em HTML o desenho apresentado. Recortaram-se as imagens e definiram-se como fundo das tabelas. O menu de botões já estava implementado com tabelas e javascript, bastou portanto alterar para as novas cores. Mesmo assim, este novo layout estava muito ‘morto’ e precisava de mais vida. O menu de botões teria que ser na horizontal, pois começava a ocupar uma grade parte da página. Então o designer fez um novo trabalho e criou uma imagem para colocar no topo da página e assim dar mais vitalidade. Este resultado é o layout final do site. (Figura 12) Daniel Nogueira 47
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 12 – Layout final do site 5.1 Conclusão Este capítulo deu a conhecer os dois protótipos que deram origem ao site final. O primeiro protótipo mais numa perspectiva de suportar as funcionalidades a implementar. O segundo já com uma perspectiva de aperfeiçoamento e para a versão final. Ambos os protótipos contribuíram para a construção do site final. Foi essencial a existência deste capítulo para perceber como se chegou à versão final do site. Daniel Nogueira 48
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 6 Aplicação final Este capítulo descreve a versão final do site. Esta versão resultou do melhoramento das versões anteriores a nível de código e de design. Nos seguintes sub-capítulos serão explicadas todas as funcionalidades implementadas. 6.1 Estrutura do site e funcionamento geral A estrutura do site é o esqueleto sobre o qual o site está montado. Este esqueleto é feito com base em tabelas HTML (Extracto XX2) e o aspecto visual como tipos de letras, cores e imagens de fundo são definidos por CSS. Existe uma tabela com uma linha e uma coluna que se ajusta ao tamanho da janela do browser. Dentro desta tabela existe uma outra que vai conter 4 células de margem para permitir que em diferentes resoluções estas ocupem o espaço que poderá sobrar, pois a célula central onde aparecerá o conteúdo do site tem tamanho fixo. Também ao redimensionar a janela serão estas margens que se vão ajustar. A célula central ira conter mais uma tabela que será incluída através do ficheiro ‘tabela_central.php’. Este ficheiro define então toda a estrutura da página propriamente dita. Tem então uma tabela principal com uma célula para se ajustar à célula central da tabela anterior, e dentro desta nova célula contém uma nova tabela com 4 linhas. Na primeira linha aparece a imagem de topo e o menu de botões, na segunda linha aparece o número de visitas, a zona de login ou a barra de estado, na terceira linha, e muito importante para o modo como se carregam as paginas, temos uma célula vazia que tem como id ‘contentor’. O porque desta célula com id será explicado mais à frente. E na última linha da tabela está alguma informação sobre o site, como o email de apoio e data de actualização. Daniel Nogueira 49
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 2 – Estrutura do site Este site não tem um funcionamento normal semelhante à maioria dos sites. Normalmente num site com tabelas é criada primeiramente a estrutura base, e a partir daí fazem-se todas as páginas com base nessa estrutura. Quando se faz uma mudança de página, esta é totalmente carregada, ou seja, as partes comuns que não necessitariam de actualização são sempre carregadas, o que implica maior tráfego de informação e maior tempo de carregamento. Em alguns casos podem-se usar iframes para evitar o refrescamento de uma página completa, então só o conteúdo do iframe será actualizado. • FUNCIONAMENTO GERAL DO SITE Neste site optei por fazer uso da ‘tecnologia’ Ajax do seguinte modo: Como já foi referido atrás, existe uma célula que contém um id. Esta célula será tratada como um contentor. Contentor este que vai ser o suporte para o aparecimento dos dados relativos às novas páginas. Assim sendo, só este contentor será actualizado na mudança de página. Daniel Nogueira 50
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Existem vários ficheiros que contêm os dados que irão aparecer neste contentor. Agora só falta fazer com que essa informação seja carregada. Por exemplo, quando se clica no menu de botões para vizualizar outras partes do site, a informação pretendida que estará previamente definida em ficheiros terá que ser mostrada. Para fazer aparecer o conteúdo desses ficheiros no contentor é usado Ajax e DOM. Ajax para efectuar o pedido da página ao servidor, e DOM para fazer aparecer o conteúdo da página no contentor. Cada vez que é click um botão do menu é chamada uma função (Extracto XX3) JavaScript que trata de efectuar o pedido das páginas. Extracto 3 – Função que efectua o pedido das páginas por Ajax Esta função faz o pedido da página pretendida e quando recebe os dados do servidor, coloca-os no contentor. Problemas deste método Existem algumas desvantagens na utilização de Ajax para carregar as páginas: • O código JavaScript contido nessas partes carregadas por Ajax não funcionará, pois não é feito o parse do código. • Não será possível retroceder para as páginas visitadas. Daniel Nogueira 51
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Para resolver o primeiro problema, todas as funçoes JavaScript necessárias para que as partes incluídas por Ajax funcionem existirá num ficheiro ficheiro JavaScript de nome igual ao nome da pagina, mas com extensão ‘.js’, e serão incluídos todos na pagina inicial. Assim estarão disponíveis quando a parte da página correspondente for carregada. 6.2 Estrutura de ficheiros O site tem o nome de Protoreg e a estrutura de ficheiros é a seguinte: Figura 13 – Estrutura de ficheiros A pasta principal tem o nome de protoreg, dentro dela encontram- se três pastas: • Img – pasta de imagens; • Includes – nesta pasta encontram-se várias pastas: o Classes – está pasta contém uma classe PHP (phpmailer) para o envio de mensagens de email; o Css – contém os ficheiros de css; o Funcs – contém uma função que faz a ligação à base de dados quando é incluída num ficheiro php. Contém também uma função para gerar as passwords. o JPGraph – contém a classe JPGraph; o Js – contém todos os ficheiros javascript o Paging – contém um ficheiro para paginação que é usado para paginar as notícias. Daniel Nogueira 52
    • PROTOREG – Programa piloto de registo de intoxicações alimentares o Noticias – onde estão todos os ficheiros usados para as notícias. 6.3 Ficheiro de configuração Foi definido um ficheiro de configuração onde se definem vários parâmetros. Se quisermos alterar a estrutura de ficheiros ou a localização do site, basta-nos alterar as várias definições neste ficheiro. Também podemos mudar aqui os parâmetros de ligação à base de dados. Extracto 4 – Ficheiro de Configuração Para que o ficheiro de configuração tenha a utilidade pretendida terá que ser incluído em todos os ficheiros. Surgiu um problema quando se tentava incluir este ficheiro, pois dependendo da localização dos outros ficheiros o caminho variava. E quando um ficheiro incluía outro que por sua vez incluía o ficheiro de configuração o caminho relativo assumido era em relação ao primeiro ficheiro. Então para resolver este problema foi criado um pequeno Daniel Nogueira 53
    • PROTOREG – Programa piloto de registo de intoxicações alimentares módulo (Figura 12) que foi inserido em todos os ficheiros para fazer incluir correctamente o ficheiro de configuração. Extracto 5 – Módulo de inclusão do ficheiro de configuração Explicação do funcionamento deste pequeno módulo: • A variável $level define o número de directórios a percorrer para chegar à raiz. Se o ficheiro já se encontra na raiz o nível é zero, se se encontra acima da raiz um directório o nível é 1; • Em primeiro lugar verificamos se está definida a variável $level (nível); o se não estiver definida, significa que o ficheiro não está a ser incluído a partir de outro, e então o nível será o nível desse ficheiro é relação à raiz; o Se estiver definida, significa que o ficheiro está a ser incluído noutro ficheiro e então a variável já terá o valor correcto do nível do ficheiro que o incluiu. • Depois faz-se um pequeno ciclo que vai criar uma string com a primeira parte do caminho relativo; Por exemplo: o $level = 0; t $x = “”; o $level = 1; t $x = “../”; o $level = 2; t $x = “../../”; • E por último inclui o ficheiro de configuração. Se o ficheiro já tiver sido incluído antes não volta a ser incluído. Daniel Nogueira 54
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 6.4 Sistema de autenticação O sistema de autenticação permite que um utilizador não registado na tenha acesso a algumas partes do site. Para fazer o controlo das autenticações recorreu-se ao uso de variáveis de sessão. Quando um utilizador entra no site, depois de inserir o email e a palavra passe são criadas várias variáveis de sessão com alguma informação sobre ele, como o nome, o tipo de utilizador, o número de visitas e a data da última visita. A validação do utilizador quando este introduz o email e a palavra passe é efectuada utilizando uma função JavaScript e Ajax. 6.4.1 Do lado do cliente Extracto 6 – Função validaLogin Esta função em JavaScript recebe dois parâmetros, email e password que foram inseridos pelo utilizador. É criado um objecto da classe ‘sack’ responsável pela comunicação com o servidor. Define-se o ficheiro que se encontra no servidor e que vai ser responsável pelo tratamento do pedido e envio da resposta, que é o ficheiro “valida_login_ajax.php”. Daniel Nogueira 55
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Definem-se as variáveis email e password, e o método http de transferência de dados, neste caso “POST”. Pode também definir-se um elemento html HTML onde irá aparecer o estado da comunicação. Depois definimos quatro funções que vão sendo chamadas de acordo com a evolução do pedido resposta. Quando o pedido foi enviado e a resposta foi recebida a última função analise o conteúdo da resposta e verifica então se o script do servidor validou ou não o email e a password. Se a resposta for “1” a autenticação foi bem sucedida, se a resposta for diferente não teve sucesso e será apresentada uma mensagem de erro. A última linha de código desta função faz com que o pedido seja efectuado. Só pode ser feito o pedido depois de bem definido o objecto ‘sack’. 6.4.2 Do lado do servidor O ‘server side script’ que valida o email e a password é apresentado a seguir. Daniel Nogueira 56
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 7 – Valida login do lado do servidor Este script recebe por “POST” as variáveis definidas no cliente (Figura 10). Efectua uma query à base de dados para verificar se o email e a password existem e correspondem. Se existe e correspondem então é actualizado o número de autenticações do utilizador e são criadas as diferentes variáveis de sessão. 6.5 Administração Neste sub-capitulo vai ser apresentado o sistema de administração do site. O sistema de administração é uma área do site onde só os administradores têm acesso. É nesta área que os dados vão ser importados através de ficheiros em formato (csv) recebidos dos hospitais relativos aos casos de intoxicações alimentares. Posteriormente esses dados serão tratados por uma pessoa responsável. Daniel Nogueira 57
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 14 – Zona de Administração 6.5.1 Importação de dados Os dados hospitalares são recebidos através de ficheiros no formato Comma Separated Value (csv). Para os introduzir na base de dados foi criado um script que automaticamente faz essa importação.Este script sofreu várias alterações desde a primeira versão porque os dados recebidos nem sempre se encontravam no mesmo formato. Figura 15 – Formato CSV dos dados recebidos O primeiro valor (COD_PROTOREG) vai ser o código de registo na tabela ‘Protoreg’, e a cada registo pode ter vários ‘DIARIO’. No ficheiro csv várias linhas eram repetidas diferindo só no valor ‘DIARIO’. Ao ler o ficheiro linha a linha quando se encontra um novo ‘COD_PROTOREG’ diferente inserem-se todos os valores na tabela ‘Protoreg’ à excepção do ‘DIARIO’, que é inserido na tabela ‘Proto_diario’ juntamente com ‘COD_PROTOREG’ para que haja associação entre o código e o diário. Para cada linha em que o ‘COD_PROTOREG’ se repita são inseridos somente o código e o diário na tabela ‘Protoreg’. Daniel Nogueira 58
    • PROTOREG – Programa piloto de registo de intoxicações alimentares A cada código diferente é também inserido nas tabelas ‘Proto_diag_base’, ‘Proto_trata’ e ‘Proto_analises’ um registo para fazer a relação entre estas tabelas e a tabela ‘PROTOREG’. Inicialmente era um trigger que se encarregava de fazer esta operação, mas SGBD onde iria ficar alojada toda a informação era de uma versão anterior de MySQL que ainda não suportava triggers. Figura 16 – Pop-up para importação dos dados O ficheiro a importar terá que estar no formato correcto, caso contrário aparecerá uma mensagem de erro não há alterações da base de dados. 6.5.2 Inserir comentários nos registos É possível que o responsável aquando do tratamento de dados queria introduzir um comentário ou uma pequena nota sobre cada registo. Para isso existe a possibilidade de inserir e editar o campo comentário. Esta funcionalidade utiliza a ‘tecnologia’ Ajax para comunicar com o servidor e DOM para manipular dinamicamente os elementos HTML. Ao carregar na imagem de editar aparece dinamicamente uma caixa de texto que herda o texto que possa estar na célula correspondente ao comentário. Então o utilizador insere o seu comentário, e tanto pode cancelar como aceitar a mudança . Daniel Nogueira 59
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • Se cancelar a caixa de texto desaparece e volta tudo ao estado inicial; • Se aceita, é feito um pedido para o servidor onde é enviado o texto com o comentário através de um HTTPRequest. Assim o texto é gravado na base de dados quando o pedido chega ao servidor, e o texto da célula é alterado para o texto que está na caixa de texto e esta desaparece. Isto tudo ocorre sem que haja refrescamento da página. Entretanto, mesmo que o pedido de mudança não seja completo, o utilizador poderá ir efectuando outras tarefas. Figura 17 – Inserir comentário Figura 18 – Comentário inserido 6.5.3 Tratamento de dados A zona propriamente dita de tratamento dos é apresentada a seguir. Aqui a pessoa responsável após ler e analisar o diário do paciente vai introduzir alguns dados nesta área de acordo com vários parâmetros que vão reflectir no fundo o porque da deslocação ao hospital entre outros. Daniel Nogueira 60
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 19 – Pop-up para edição/inserção de dados Esta imagem é o pop-up que aparece quando se clica no número de código na zona de administração (Figura 15). Cada barra azul quando clicada, mostra ou esconde partes do formulário que permite a introdução de dados. Depois de todos ou alguns dados serem introduzidos, existem duas opções: • Aceitar – neste caso os dados contidos nos formulários são submitidos por POST para outro script que se vai encarregar de tratar os dados, fazer a ligação ao servidor e inserir ou actualizar todos os dados. Quando este processo acabar aparece uma mensagem a confirmar o sucesso da operação, e volta-se automaticamente para a página de administração inicial (Figura 15). • Fechar – os dados serão todos descartados e volta-se à página inicial (Figura 15). Daniel Nogueira 61
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 20 – Inserção de sintomas e antecedentes Quando são expandidas as abas dos sintomas e antecedentes, aparece a imagem anterior (Figura 21). Na caixa da direita aparecem as opções. Podem ser seleccionados vários ao mesmo tempo e envia-los para a caixa da esquerda. Se o sintoma ou antecedente pretendido ainda não constar da base de dados existe a possibilidade de adicionar um novo, inserindo na caixa de texto e clicando em inserir. Figura 21 – Inserção de agentes Da mesma forma se procede para inserir novos agentes, com a particularidade de que um agente pode ter tipo: • “bactéria”; • ”vírus”; • “protozoário”. Então existe uma caixa de selecção para indicar que tipo de agente se vai introduzir. Daniel Nogueira 62
    • PROTOREG – Programa piloto de registo de intoxicações alimentares O processo responsável por fazer estas inserções é feito recorrendo à ‘tecnologia’ Ajax e DOM e será apresentado a seguir com extractos de código explicados. Extracto 8 – Função doit A função ‘doit’ recebe vários parâmetros e é capaz de tratar tanto da inserção de sintomas, antecedentes, agentes possíveis e identificados. Explicação dos parâmetros recebidos: • campo – este parâmetro tem 3 valores possíveis, o sintoma – no caso de sintoma; o antecedente – no caso de antecedente; o agente – para a inserção de agentes; • tipo – quando se trata de um agente este campo refere que tipo de agente se trata: Daniel Nogueira 63
    • PROTOREG – Programa piloto de registo de intoxicações alimentares o 1 – bactéria; o 2 – vírus; o 3 – protozoário; o null – não existe tipo, pois não se trata de um agente. • value – é o texto que é inserido na caixa de texto, ou seja, o nome do sintoma, do agente ou do antecedente; • tObj1 – este parâmetro é em todos os casos a caixa de selecção mais à esquerda, que é onde vai ser inserida dinamicamente através do DOM a nova opção inserida. • tObj2 – relativamente aos agentes, existem dois sítios diferentes onde podem ser inseridos, na zona dos agentes possíveis e nos agentes identificados (Figura 22). Então tem que existir um segundo objecto de destino da nova opção. Este último objecto é então a caixa da direita da zona onde não foi inserido o agente, isto para que o agente fique logo disponível nos dois lados. Verificam-se depois estes parâmetros para identificar que tipo de inserção vai ser efectuada. Usa-se mais uma vez a classe sack para comunicar com o servidor. Então vão ser enviadas as seguintes variáveis por POST: • value – esta variável é enviada com o nome igual ao campo. Por exemplo: setVar(‘sintoma’,’nome do sintoma’) e setVar(‘antecendete’,’nome do antecedente’). Então no lado do servidor dependendo do tipo de campo vai existir uma variável POST: $_POST[‘sintoma’] ou $_POST[‘antecedente’] … • tipo – se o tipo for deferente de null é enviada também uma variável para dar informação do tipo de agente. Daniel Nogueira 64
    • PROTOREG – Programa piloto de registo de intoxicações alimentares É enviado entaoentão então o pedido ao script ‘insert_saa.php’ que se encontra no servidor e que se vai responsabilizar por inserir a informação na base de dados. Extracto 9 – Primeira parte do script ‘insert_saa.php’ Esta é a primeira parte do código do script que recebe o pedido do lado do servidor. Começa-se por definir uma variável de controlo e um cabeçalho XML. Verifica-se então as variáveis POST recebidas para determinar qual vai ser a inserção. Daniel Nogueira 65
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 10 – Segunda parte do script ‘insert_saa.php’ Se a variável de controlo tiver activa (com valor 1) significa que já está definida qual a acção a tomar. Tem que se descodificar o texto recebido por POST, pois este sofre uma codificação antes de ser enviado ao servidor. De seguida é definida uma query sql dependendo do tipo e campo, que vai ser executada para verificar se o valor a inserir já se encontra na tabela correspondente. Se for repetido não se vai inserir novamente, e é então criado um pequeno texto XML que vai ser enviado ao cliente com dando a informação que está repetido. No caso texto XML é o seguinte: Extracto 11 – Resposta XML (Repetido) Se não está repetido é criada a string sql adequada para fazer a inserção, e regista-se qual foi o id com que o registo ficou e envia-se como resposta para o cliente: Daniel Nogueira 66
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 12 – Resposta XML (Inserido) Se por algum motivo ocorrer algum erro ao fazer o insert na base de dados é enviada a seguinte resposta: Extracto 13 – Resposta XML (Erro) Quando a resposta é recebida pelo cliente, este analisa o texto XML para determinar o sucesso da operação. Se ocorreu com sucesso o sintoma, agente ou antecedente é inserido dinamicamente através de DOM na caixa de selecção. A função responsável por tratar a resposta XML é explicada mais à frente e é chamada quando o pedido ao servidor é totalmente completo: Extracto 14 – Função executada quando o pedido é completado No extracto seguinte pode-se visualizar a chamada da referida função, que leva como parâmetro a string XML contida na resposta. Daniel Nogueira 67
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 15 – Primeira parte da função newCampo Nesta função é criado um objecto XML com base na string recebida. Existem diferenças no modo de criação deste objecto entre o Internet Explorer e o FireFox, para isso é necessário identificar qual o browser que está a ser usado. Depois de criado o objecto, existem também algumas diferenças nos métodos para percorrer o objecto XML nomeadamente para aceder ao valor de um nodo. No caso do Internet Explorer é usada a propriedade node.text enquanto que no FireFox é node.firstChild.data. A informação útil que vai ser retirada deste objecto é o nome do primeiro nodo, o atributo id e o texto. O nome do nodo dá-nos indicação se estamos perante um sintoma, um antecedente ou um agente. Daniel Nogueira 68
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 16 – Segunda parte da função newCampo Verificamos se o id é -1 ou -2 para o caso de ter ocorrido alguma excepção. Caso contrário é criado um objecto HTML (Option) que vai ser adicionado através do HTML DOM na caixa de selecção destino (targetObj1). Se ‘targetObj2’ está definido, no caso dos agentes, é criado outro objecto Option e é inserido na outra caixa de selecção como foi referido anteriormente. 6.6 Contador de visitas O contador de visitas é controlado por uma variável de sessão. O objectivo dessa variável é impedir que seja contabilizada uma visita pelo simples facto de se fazer um refresh à página. Extracto 17 – Chamada da função incrementa_visitas Daniel Nogueira 69
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Quando carrega a página principal (index.php), verifica se existe já definida a variável de sessão. Se não existe significa que é a primeira vez na sessão que o utilizador acede à página, e neste caso é então criada a variável que vai ficar com o número de visitas actual mais um. Extracto 18 – Função incrementa_visitas Para isso usa-se a função incrementa_visitas que determina qual o número de visitas que se encontra na base de dados na tabela ‘visitas’, depois incrementa o valor em um, actualiza o campo e retorna o valor actual para a variável de sessão. Enquanto esta estiver definida, ou seja, enquanto o browser não for desligado o número de visitas não será mais aumentado. Evitando assim a incrementação abusiva do número de visitas. 6.7 Estatísticas O sistema de divulgação estatística dos dados é talvez a parte mais importante do site. Permite os utilizadores registados de uma forma simples e intuitiva ter a noção destes problemas que são as intoxicações alimentares. Nesta primeira fase do projecto apenas foram criados gráficos 3 tipos de gráficos: • Totais presumíveis; • Totais presumíveis por sexo; • Totais presumíveis por faixa etária. Daniel Nogueira 70
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Estes gráficos estão predefinidos, e reflectem os dados existentes a cada momento na base de dados. Estão constantemente actualizados. Figura 22 – Gráfico de totais presumíveis Figura 23 – Gráfico de totais presumíveis por sexo Daniel Nogueira 71
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 24 – Gráfico de totais presumíveis por faixa etária O utilizador poderá ainda obter gráficos personalizados: • Entre duas datas (Figura 25); • De vários meses de vários anos, isto é, por exemplo (Figura 26): o Vários meses de um ano; o Vários meses de vários anos; o Um mês de vários anos; Figura 25 – Gráficos entre duas datas Figura 26 – Gráficos personalizados Daniel Nogueira 72
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Quando é definido e visualizado um gráfico (Figura 27) é sempre possível imprimir, para que este possa ficar registado em papel. Figura 27 – Personalização de gráficos Quando se clica em ‘imprimir’ aparece-nos um pop up com o gráfico a imprimir. A razão pela qual se cria este pop up é que a função print() de JavaScript imprime tudo o que estiver na janela, por isso com o pop up só se imprime o gráfico evitando imprimir as partes que não nos interessam (Figura 28). Daniel Nogueira 73
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 28 – Pré-visualização dos gráficos para imprimir 6.7.1 Estrutura da zona de estatística Todo este processo de construção e visualização dos gráficos tem por base o uso da classe JPGraph. A esta classe possibilita a criação de vários tipos de gráficos, mas vão ser só usados os gráficos de barras. Resumidamente, existem três scripts PHP que recebem alguns dados por GET da página de personalização (Figura 26 e 27). Estes scripts tratam os dados e retornam uma imagem que corresponde ao gráfico. Na página de personalização existe um div escondido que contem uma imagem sem url. Através de funções JavaScript vão ser validados os valores inseridos na página, e então é dinamicamente através de DOM atribuído um novo url à imagem dentro do div escondido e este é mostrado. O url será o nome do script PHP responsável pela criação e retorno do gráfico pretendido. 6.7.2 Criação dos gráficos Para auxiliar a criação dos gráficos a informação das tabelas foi organizada em views: Campo Tipo de Dados Comentário Daniel Nogueira 74
    • PROTOREG – Programa piloto de registo de intoxicações alimentares data datetime Data do registo ano bigint(21) Ano do registo mes bigint(21) Mês do registo Totais de casos agrupados relativos ao totais bigint(21) ano/mes Totais de casos agrupados relativos ao confmedico bigint(21) ano/mes Totais de casos agrupados relativos ao confanalise bigint(21) ano/mes Tabela 18 – View totaispres Esta view agrupa os dados por ano e por mês, assim dá-nos a informação mais organizada dos totais de casos. O campo ‘data’ é do tipo date, e serve exclusivamente para permitir ordenar e agrupar os valores na tabela por data. Os campos ‘ano’ e ‘mes’ Campo Tipo de Dados Comentário data datetime Data do registo f1 bigint(21) Totais da faixa etária 1 f2 bigint(21) Totais da faixa etária 2 f3 bigint(21) Totais da faixa etária 3 f4 bigint(21) Totais da faixa etária 4 f5 bigint(21) Totais da faixa etária 5 Tabela 19 – View pfe_2 Esta view agrupa os dados por data e por faixa etária. Campo Tipo de Dados Comentário data datetime Data do registo masculino bigint(21) Totais masculino feminino bigint(21) Totais feminino Tabela 20 – View sexopordia Esta view agrupa os dados por dia, depois teremos que ‘pegar’ nesta view e agrupar da forma necessária. Daniel Nogueira 75
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 6.7.3 Explicação do código Para ser possível a criação dos gráficos de barras é necessário incluir os seguintes ficheiros: Extracto 19 – Incluindo ficheiros Define-se o título do gráfico, o título das abcissas e um array com as iniciais dos meses que vão ser usadas para identificar a que mês corresponde as barras dos gráficos. Extracto 20 – Definindo títulos e nome dos meses Determinam-se quais os dados recebidos para se identificar qual vai ser o processo para criação do gráfico. Existem as duas possibilidades já referidas: • Entre duas datas; • Vários meses/vários anos Para cada um deles os dados enviados por GET variam. Se estão definidas as variáveis $GET[‘ini’] e $_GET[‘fim’] então é entre duas datas, caso contrário é a outra possibilidade. Com dois ciclos for aninhados, o primeiro a percorrer os anos a começar no ano inicial até ao final, o segundo a percorrer do mês inicial até ao final. Para cada iteração vão sendo criados os arrays com os valores para cada mês de cada ano inicializados a zero, e um array com a string mês/ano correspondente. Depois é criada a string sql responsável por extrair os dados da base de dados com base nas views acima referidas. Daniel Nogueira 76
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 21 – Verificação de Variáveis Se não estão definidas estas variáveis GET então o processo é diferente. Verificam-se então outras variáveis definidas, e de acordo com a existência ou não de certas variáveis, vai ser definido um tipo de filtro diferente que vai ser útil para determinar qual a string sql que terá de ser usada. Daniel Nogueira 77
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 22 – Continuação do extracto anterior Depois de determinado o tipo de filtro define-se a string sql. Caso o filtro seja zero, é logo executada a query e determinados os valores. Extracto 23 – Continuação do extracto anterior Se o filtro for diferente de zero é necessário executar a query definida para determinar os arrays de dados e determinar a escala com base no valor mais alto. Daniel Nogueira 78
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Como os arrays podem conter valores meses/anos inicializados a zero que não foram reescritos com dados novos, então serão eliminados com os ciclos foreach no extracto de código a seguir. Extracto 24 – Continuação do extracto anterior Neste momento os arrays de dados estão prontos, e só nos resta definir o gráfico e os seus atributos. A largura e altura do gráfico é calculada em função do tamanho de posições dos arrays, ou seja, quantos mais posições no array mais largo terá que ser o gráfico. O extracto a seguir está bem comentado e percebe-se facilmente qual é o objectivo de cada método. Daniel Nogueira 79
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 25 – Continuação do extracto anterior Daniel Nogueira 80
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 6.8 Notícias As notícias podem ser consultadas por todos os utilizadores registados. Existe uma barra de navegação que permite ao utilizador saltar de página em página, e um campo de pesquisa em que se pode pesquisar por palavra. Figura 29 – Zona de notícias Toda a zona onde aparecem as noticias, a barra de pesquisa e a barra de navegação é um iframe, assim evita que tenha que se refrescar a página toda só para saltar de uma página para outra. Na base de dados o título e o texto da notícia não necessitam ter estilo definido, pois quando são escritas na página são inseridas dentro de tabelas que contém aplicado um estilo CSS. Portanto, se por qualquer motivo for necessário alterar a cor, o tipo ou tamanho de letra, etc, basta alterar o estilo CSS correspondente. Daniel Nogueira 81
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Ao serem carregadas as notícias na página, só aparece o texto inicial. Isto permite que o utilizador identifique melhor as notícias que lhe interessam. Para visualizar todo o texto de uma notícia basta clicar no título ou nos três pontinhos entre parênteses (…). Ao ser clicado um destes itens, a página de notícias anterior (Figura 29) vai ser escondida e é mostrado um div que contém o texto completo da notícia (Figura 30). Figura 30 – Visualização de uma notícia Depois de lida a notícia, ao clicar em ‘voltar’ ou na imagem o div com o texto é escondido e a página de notícias passa para o estado visível. Daniel Nogueira 82
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Ao ser pesquisada uma palavra, aparecem todas as notícias onde essa palavra ocorre, e a palavra aparecerá com fundo amarelo como na Figura 31. Figura 31 – Pesquisando por palavra-chave Problemas encontrados: Para que apareça apenas o texto inicial das notícias nas páginas, é necessário dividir o texto. O método utilizado foi: • Ler o texto da notícia; • Criar um array com as palavras todas; • Escrever só as primeiras 100 palavras; Como o texto pode conter código HTML, algumas tags poderiam não ser fechadas, e isso iria causar má formatação no resto da página. Para contornar esse problema foi criada uma classe (ANEXO X3) que processa uma string com as primeiras 100 palavras do texto. Caso Daniel Nogueira 83
    • PROTOREG – Programa piloto de registo de intoxicações alimentares nessa string existam tags HTML abertas e não sejam terminadas, esta classe tratará de as fechar. Assim o código HTML fica correcto e a página ficará como se pretende. Caso o código HTML esteja mal formatado já na base de dados, esta classe poderá não ser eficaz. Pois só serão fechadas correctamente as últimas tags abertas. 6.8.1 Inserir notícias Os administradores serão as pessoas responsáveis pela inserção de notícias. O link para esta página (Figura 14) está na zona de administração (Figura 14). Figura 32 – Zona de inserção de notícias É usado um editor HTML, FCKEditor [10]. Este editor funciona todo sobre JavaScript, é um editor muito completo e muito parecido com o Microsoft Word. Este processo de inserção de notícias funciona com a ‘tecnologia’ Ajax e JavaScript DOM, e que faz com que se assemelhe a uma aplicação desktop. Daniel Nogueira 84
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • Funcionamento Depois de inserido o título e texto da notícia, podemos escolher se a noticia vai ficar logo publicada, ou se vai só ficar guardada. Ao clicar em guardar é usado um objecto da classe sack como já foi explicado anteriormente. Extracto 26 - Função que comunica com o servidor para tratar notícias Esta função é responsável por efectuar o pedido ao servidor, onde define a acção e os dados a enviar. O script ‘inserir_s.php’ está à espera do lado do servidor, e quando o pedido chega verificam-se os dados recebidos e determina-se a acção a executar. • Inserir – determina o texto, o título e se a notícia vai ser publicada ou não. o Determina a data de sistema para atribuir à data de criação da notícia; Daniel Nogueira 85
    • PROTOREG – Programa piloto de registo de intoxicações alimentares o Cria a string sql para inserir a notícia na base de dados; o Depois de inserido na base de dados determina o id inserido; o Prepara a resposta XML e envia para o cliente; Extracto 27 – Extracto da verificação da acção no servidor Extracto 28 – Função que escreve a resposta XML no servidor A razão pela qual o texto é codificado é que não podemos colocar código HTML dentro de tags XML, pois não há distinção entre as tags, e as tags seriam tratadas como se fossem todas XML. Daniel Nogueira 86
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Assim o texto é codificado para poder ser enviado, e quando chega ao cliente, depois deste ter retirado a informação que cada tag contém é então descodificado para se obter o valor original. A função que trata da resposta é a seguinte: Extracto 29 – Função que trata a resposta XML recebida do servidor Na página de inserção de notícias existem algumas variáveis globais que dão informação a cerca do estado da notícia em processamento. Extracto 30 – Variáveis de controlo Daniel Nogueira 87
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 31 – Variáveis temporárias de controlo A função ‘trataResposta’ (Extracto 29) percorre o objecto XML e retira toda a informação necessária para preencher as variáveis temporárias. Depois disto, e dependendo da acção executada, as variáveis temporárias vão ser atribuídas às outras variáveis. Extracto 32 – Continuação da função trataResposta No caso de uma inserção ou actualização, o tratamento é igual. Caso seja abrir, para além desta atribuição de variáveis, tem que se introduzir o texto e título recebido no editor. Para isso é usada a API Daniel Nogueira 88
    • PROTOREG – Programa piloto de registo de intoxicações alimentares do FCKEditor, em que instanciamos a caixa de texto do editor e usando o método SetHTML conseguimos definir qual o texto para aparecer no editor (Extracto 33). Extracto 33 – Utilizando a API do FCKEditor Em qualquer altura é possível abrir uma notícia, para editar ou alterar o estado de publicação. Ao clicar em abrir aparece o seguinte popup, que carrega por Ajax o título das notícias disponíveis e cria a combo box com esses títulos. Quando se atingir um número grande de noticias este método deixa de ser eficaz, e terá que ser alterado. Serão inicialmente carregadas apenas as últimas notícias, com opção de escolher entre duas datas. Uma vez que o projecto vai ser continuado, será implementado mais tarde. Figura 33 – Popup para abrir notícia Este popup é gerado dinamicamente e em tempo de execução quando se clica em ‘abrir’ (Ffigura XX32) que chama a seguinte função. Daniel Nogueira 89
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 34 – Função abrir O extracto anterior contém o código responsável pelo aparecimento do popup da Figura 33. Seleccionando uma notícia e carregando em ‘Abrir notícia’ será chamada outra função ‘abrir’ que está definida no ficheiro ‘abrir_noticia.js’ incluído. Extracto 35 – Função abrir (no ficheiro abrir_noticia.js) Esta função por sua vez chama a função ‘ajax’ explicada anteriormente (extracto 26) com os argumentos ‘accao = abrir’ e ‘id = id_noticia’. Então como já foi visto é feito um pedido ao servidor com a acção de abrir. O servidor envia o XML como resposta para o cliente em que o formato é o seguinte. Extracto 36 – Resposta XML do servidor Daniel Nogueira 90
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 6.9 Registo O formulário de registo (Figura XX34) é uma parte muito importante do site, uma vez que é o caminho que um utilizador tem que percorrer para poder aceder a todas as funcionalidades do site. Figura 34 – Zona de registo Os campos obrigatórios são assinalados com asteriscos. O conteúdo destes campos é validado por funções JavaScript com expressões regulares, como é o exemplo da validação do email (Figura XX35). Daniel Nogueira 91
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 37 – Função para validar email Depois de todos os campos estarem validados, antes de submeter o formolário, vamos ainda verificar se o email já está em uso. Caso o email esteja já a ser utilizado não será possível efectuar o registo. Entao aparecerá uma mensagem JavaScript a avisar da repetição de email e o campo ficará vermelho. Figura 35 – Mensagem de email já registado O processo de verificação do email é feito no servidor e é efectuado recorrendo ao Ajax. Neste caso não foi utilizada a classe sack, pois ainda não tinha sido descoberta. Daniel Nogueira 92
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 38 – Variáveis globaisVariáveis globais Este é um método mais primitivo de usar Ajax e é a melhor maneira para compreender o seu funcionamento. São então definidas 4 variáveis globais (Extracto 38): • http – objecto XMLHttpRequest criado pela função ‘getHTTPObject’; • url – localização do server side script; • isWorking – para controlar que só pode estar a fazer um pedido de cada vez. • EmailValido – no fim da resposta recebida esta variável diz-nos se o email foi validado ou não. Extracto 39 – Função para criar o objecto XMLHttpRequest Daniel Nogueira 93
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Esta função é multi-plataforma, funciona em Mozilla, Firefox, Safari, Opera e Internet Explorer. Extracto 40 – Função que faz a comunicação com o servidor Esta função faz o pedido por Ajax. Verifica se o objecto http está definido e se não está a ser usado. Acrescenta a string email no url para enviar por GET, e faz o pedido ao servidor. Este pedido passa por 4 estados (http.readyState): • 1 – os dados estão a ser enviados; • 2 – os dados foram enviados; • 3 – a resposta esta a ser recebida; • 4 – a resposta foi totalmente recebida. Cada mudança de estado é detectada pela propriedade onreadystatechange que vai chamar a função responsável por verificar qual o estado do pedido e efectuar as operações necessárias. A função seguinte (Extracto 41) é chamada sempre que o estado do pedido muda, verificando qual é o estado. Para os estados 1,2 e 3 faz aparecer apenas um div com a informação do estado do pedido (Figura 36). Daniel Nogueira 94
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Extracto 41 – Função handleHttpResponse Figura 36 – Div com estado do pedido Daniel Nogueira 95
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Quando o estado é 4 o div com a informação é escondido, e é verificada a resposta do servidor: • ‘0’ – o email já existe, então não pode ser registado novamente; • ‘1’ – o email ainda não está registado. O script que trata o pedido no servidor e verifica se o email pode ou não ser registado é tem como nome ‘_validaEmail.php’ e é apresentado a seguir: Extracto 42 – Código no servidor que verifica se o email já está registado Este script é simples, apenas faz uma query à base de dados para verificar se o email já existe. Se existe a resposta é negativa, caso contrário e resposta é positiva e o email poderá ser registado. Depois de verificado o último estado do pedido (Extracto 41) a resposta é analisada, e temos entao duas possibilidades: • ‘EmailValido = 0’ – aparecerá uma mensagem de erro (Figura 37); • ‘EmailValido = 1’ – aparecerá uma mensagem a confirmar o sucesso do registo (Figura 37); Daniel Nogueira 96
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Figura 37 – Mensagem de erro ao registar Figura 38 – Mensagem de sucesso do registo Daniel Nogueira 97
    • PROTOREG – Programa piloto de registo de intoxicações alimentares No caso de sucesso do registo, é enviado um email com a password de acesso ao site. É utilizada uma função que gera a password (Extracto 43) e uma classe de envio de email para gerar o email a enviar (Extracto 44). Extracto 43 – Função para gerar a password Extracto 44 – Gerar email a enviar 6.10 Conclusão A versão final do site é o conjunto de todas as funcionalidades implementadas agregadas ao desenho que é a interface. Este capítulo descreve o princípio fundamental de funcionamento geral do site. São apresentados a estrutura de ficheiros e os métodos tomados para a resolução dos problemas. Através da explicação de extractos de código e imagens da interface tenta-se dar a entender as soluções tomadas para as funcionalidades mais importantes. Daniel Nogueira 98
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 7 Conclusão Neste capítulo será feito o rescaldo final do trabalho realizado, serão focados vários pontos como: objectivos atingidos, melhoramentos possíveis e trabalho futuro, dificuldades encontradas, conhecimentos adquiridos e uma apreciação final. 7.1 Objectivos atingidos O objectivo inicial era o desenvolvimento de um site que permitisse a criação de uma plataforma de tratamento e divulgação de dados relativos a intoxicações alimentares sob a forma de gráficos e uma zona de registo de utilizadores. Estes objectivos foram atingidos. O sistema é capaz de dar suporte ao tratamento dos dados e à sua divulgação, e é possível o registo de utilizadores. As zonas de administração e publicação de notícias surgiram como objectivos secundários e foram também cumpridos. O sistema é capaz de dar suporte à criação e publicação de notícias. No decorrer do projecto houve bastantes alterações ao nível dos requisitos e a base de dados foi constantemente alterada. Esta situação provocou algum atraso na calendarização planeada. Neste momento o projecto encontra-se concluído e operacional, estando a empresa bastante satisfeita com o resultado final. O site pode ser consultado no seguinte link: www.protoreg.org. 7.2 Melhoramentos possíveis e trabalho futuro Com os testes à aplicação chegou-se a conclusão que algumas funcionalidades e outras novas poderiam ser alteradas ou acrescentadas, nomeadamente: • Criação de um fórum de discussão; Daniel Nogueira 99
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • Criação de novos tipos de gráficos para darem outros tipos de informação, como por exemplo: números de casos por distrito, quais os distritos mais afectados por determinado tipo de intoxicações, etc. • Criação de outras funcionalidades como por exemplo: possibilidade de alteração de password, etc. 7.3 Dificuldades encontradas Foram encontradas algumas dificuldades ao longo da vida do projecto que estão explicadas a seguir. • Constante alteração dos requisitos Ao longo do desenvolvimento do projecto surgiram novos requisitos, e algumas alterações que não estavam pensadas no início. Isso teve implicações ao nível da base de dados mas que foram facilmente analisadas e ultrapassadas. Em consequência destas alterações, também algumas partes do site tiveram que ser repensadas, nomeadamente na área de tratamento dos dados na zona de administração, mas que foram também facilmente ultrapassadas. • Falta de experiência A falta de experiência é sempre um contra-tempo, pois é necessário mais tempo para perceber o problema, pensar nas soluções, definir um algoritmo e implementar numa linguagem que estamos a aprender. Também para definir a interface é um processo moroso. O objectivo deste estágio foi no sentido de melhorar essas lacunas, algo que foi plenamente alcançado. 7.4 Conhecimentos adquiridos Foram aprofundados conhecimentos de HTML, XML, CSS e JavaScript. Este projecto permitiu aprofundar conhecimentos de HTML, XML, CSS e JavaScript e obter novos conhecimentos de tecnologias não abordadas durante o curso, por exemplo: Daniel Nogueira 100
    • PROTOREG – Programa piloto de registo de intoxicações alimentares • PHP – Foi muito importante adquirir conhecimentos de PHP, pois é uma linguagem muito interessante, muito útil e é muito utilizada; • Ajax – Aprender Ajax foi uma experiência muito enriquecedora, pois permitiu adquirir conhecimentos desta nova tecnologia e entender quais as suas potencialidades e as verdadeiras vantagens do seu uso; • JPGraph – Explorar a criação de gráficos estatísticos em PHP recorrendo à classe JPGraph. • MySQL – Foram adquiridos conhecimentos no uso deste SGBD, assim como do utilitário phpMyAdmin que permite interagir com o MySQL. 7.5 Apreciação final O desenvolvimento deste site foi um grande desafio. Não só permitiu a aquisição de conhecimentos de novas tecnologias, como a realização de um site de raiz. Isto levou a uma maior motivação, pois foi possível ganhar conhecimentos a todos os níveis, tanto a nível de programação, como na análise do problema. Inicialmente, o que mais me motivou no projecto foi a ideia de utilizar tecnologias novas que não são leccionadas no curso de engenharia informática como o caso do PHP, AJAX, Apache e MySQL o que permitiu obter conhecimentos muito alargados. Em jeito de conclusão e em traços genéricos, o projecto foi muito gratificante de realizar, pois, como já referi anteriormente, permitiu adquirir um vasto número de conhecimentos e experiência profissional. Daniel Nogueira 101
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 8 Bibliografia [1] Introdução à linguagem HTML, http://www.infodesktop.com/web/html/artigocompleto/1, último acesso em 24-06-2006 [2] Introdução ao CSS http://www.hugoduraes.com/2006/05/04/introducao-as- cascading-style-sheets-css/, último acesso em 24-06-2006 [3] Introdução ao PHP, http://www.truquesedicas.com/tutoriais/php/ basico/00001a.htm, último acesso em 24-06-2006 [4] Trabalhando com imagens em PHP http://www.imasters.com.br/ artigo/2116, último acesso em 24-06-2006 [5] XML nas bibliotecas digitais, http://www.bibliosoft.pt/projectoxml/_introducao.htm, último acesso em 24-06-2006 [6] Ajax: A New Approach to Web Applications, http://www.adaptivepath.com/publications/essays/archives/0003 85.php, último acesso em 24-06-2006 [7] http://www.informationweek.com, último acesso em 24-06-2006 Daniel Nogueira 102
    • PROTOREG – Programa piloto de registo de intoxicações alimentares [8] Ajax mistake, http://swik.net/Ajax/Ajax+Mistakes, último acesso em 24-06-2006 [9] Daniela Costa (2005), “Gestor de conteúdos”, ISEP, Porto, Portugal, Set 2005 [10] The editor for Internet, http://www.fckeditor.net/, último acesso em 24-06-2006 [11] Banco de dados PostgreSQL e MySQL, http://www.infowester.com/postgremysql.php, último acesso em 24-06-2006 Daniel Nogueira 103
    • PROTOREG – Programa piloto de registo de intoxicações alimentares 9 Anexos Daniel Nogueira 104
    • PROTOREG – Programa piloto de registo de intoxicações alimentares ANEXO 1 function sack() { this.xmlhttp = null; this.resetData = function() { this.method = "POST"; this.queryStringSeparator = "?"; this.argumentSeparator = "&"; this.URLString = ""; this.encodeURIString = true; this.execute = false; this.element = null; this.elementObj = null; this.requestFile = file; this.vars = new Object(); this.responseStatus = new Array(2); this.mimeType=mType; }; this.resetFunctions = function() { this.onLoading = function() { }; this.onLoaded = function() { }; this.onInteractive = function() { }; this.onCompletion = function() { }; this.onError = function() { }; this.onFail = function() { }; }; this.reset = function() { this.resetFunctions(); this.resetData(); }; Extracto 45 - Classe Sack (Parte 1) Esta classe é muito útil para trabalhar com a tecnologia Ajax, simplifica a criação do objecto XMLHttpRequest e os pedidos ao servidor. Daniel Nogueira 105
    • PROTOREG – Programa piloto de registo de intoxicações alimentares this.createAJAX = function() { try { this.xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e1) { try { this.xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); } catch (e2) { this.xmlhttp = null; } } if (! this.xmlhttp) { if (typeof XMLHttpRequest != "undefined") { this.xmlhttp = new XMLHttpRequest(); if(this.mimeType != "")//adicionado por DANOG this.xmlhttp.overrideMimeType(this.mimeType } else { this.failed = true; } } }; this.setVar = function(name, value){ this.vars[name] = Array(value, false); }; this.encVar = function(name, value, returnvars) { if (true == returnvars) { return Array(encodeURIComponent(name),encodeURIComponent(value)); } else { this.vars[encodeURIComponent(name)]= Array(encodeURIComponent(value), true); } } Extracto 46 - Classe Sack (Parte 2) Daniel Nogueira 106
    • PROTOREG – Programa piloto de registo de intoxicações alimentares this.processURLString = function(string, encode) { encoded = encodeURIComponent(this.argumentSeparator); regexp = new RegExp(this.argumentSeparator + "|" + encoded); varArray = string.split(regexp); for (i = 0; i < varArray.length; i++){ urlVars = varArray[i].split("="); if (true == encode){ this.encVar(urlVars[0], urlVars[1]); } else { this.setVar(urlVars[0], urlVars[1]); } } } this.createURLString = function(urlstring) { if (this.encodeURIString && this.URLString.length) { this.processURLString(this.URLString, true); } if (urlstring) { if (this.URLString.length) { this.URLString += this.argumentSeparator + urlstring; } else { this.URLString = urlstring; } } // prevents caching of URLString this.setVar("rndval", new Date().getTime()); urlstringtemp = new Array(); for (key in this.vars) { if(false==this.vars[key][1]&& true == this.encodeURIString){ encoded = this.encVar(key, this.vars[key][0], true); delete this.vars[key]; this.vars[encoded[0]] = Array(encoded[1], true); key = encoded[0]; } urlstringtemp[urlstringtemp.length]=key+"="+this.vars[key][0]; } this.URLString += urlstringtemp.join(this.argumentSeparator); } Extracto 47 - Classe Sack (Parte 3) Daniel Nogueira 107
    • PROTOREG – Programa piloto de registo de intoxicações alimentares this.runAJAX = function(urlstring) { if (this.failed) { this.onFail(); } else { this.createURLString(urlstring); if (this.element) { this.elementObj = document.getElementById(this.element); } if (this.xmlhttp) { var self = this; if (this.method == "GET") { totalurlstring=this.requestFile+ this.queryStringSeparator+this.URLString; this.xmlhttp.open(this.method, totalurlstring, true); } else { this.xmlhttp.open(this.method, this.requestFile, true); try { this.xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded") } catch (e) { } } Extracto 48 - Classe Sack (Parte 4) Daniel Nogueira 108
    • PROTOREG – Programa piloto de registo de intoxicações alimentares this.xmlhttp.onreadystatechange = function() { switch (self.xmlhttp.readyState) { case 1: self.onLoading(); break; case 2: self.onLoaded(); break; case 3: self.onInteractive();break; case 4: self.response = self.xmlhttp.responseText; self.responseXML = self.xmlhttp.responseXML; self.responseStatus[0] = self.xmlhttp.status; self.responseStatus[1] = self.xmlhttp.statusText; if (self.execute) {self.runResponse();} if (self.elementObj) { elemNodeName = self.elementObj.nodeName; elemNdeName.toLowerCase(); if (elemNodeName == "input"|| elemNodeName == "select" || elemNodeName == "option" || elemNodeName == "textarea") { self.elementObj.value = self.response; } else { self.elementObj.innerHTML = self.response; } } if(self.responseStatus[0]== "200") { self.onCompletion(); } else { self.onError(); } self.URLString = ""; break; } }; this.xmlhttp.send(this.URLString); } } }; this.reset(); this.createAJAX(); } Extracto 49 - Classe Sack (Parte 5) Daniel Nogueira 109
    • PROTOREG – Programa piloto de registo de intoxicações alimentares ANEXO 2 Este documento apresentado a seguir foi a base para a análise do problema proposto. Dados do doente Data de admissão: Idade: Sexo: Distrito: Motivo de deslocação ao hospital Sintomas: a) vómitos b) diarreia (características) c) dores abdominais fortes d) febre e) dores musculares f) suores g) dores nas articulações h) visão dupla i) pálpebras caídas j) dificuldade de deglutição k) abortamento ou parto prematuro l) cor da urina alterada m) icterícia n) outros Factores de predisposição/Antecedentes: a) Transplantado b) Doente oncológico c) Diabetes d) HIV e) Alcoolismo f) Gravidez g) Doença hepática crónica h) outros Diagnóstico Provável a) Intoxicação/Infecção Alimentar b) Outro Diagnóstico com base Daniel Nogueira 110
    • PROTOREG – Programa piloto de registo de intoxicações alimentares a) sintomas b) análises laboratoriais (qual o produto analisado)* c) outro Doente tem alta a) Sim b) Não Tratamento a) antibioterapia b) outro Duração da sintomatologia Evolução clínica Agentes etiológicos possíveis Bactérias Brucella spp. Bacillus cereus Campylobacter spp. Clostridium botulinum Clostridium perfringens Escherichia coli (em particular O157:H7) Listeria monocytogenes Salmonella spp. Shigella spp. Staphylococcus aureus Vibrio cholerae Vibrio parahaemolyticus Vibrio vulnificus Yersinia enterocolitica Yersinia pseudotuberculosis Daniel Nogueira 111
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Vírus Hepatite A Norovirus Rotavírus Protozoários Giardia lamblia Toxoplasma gondii Cryptosporidium spp. Análises Pedidas a)Sim b)Não Pedir resultados de análises ao hospital a)Sim b) Não Diagnóstico confirmado a) Sim b) Não Agentes etiológicos identificado Bactérias Brucella spp. Bacillus cereus Campylobacter spp. Clostridium botulinum Clostridium perfringens Escherichia coli (em particular O157:H7) Listeria monocytogenes Salmonella spp. Shigella spp. Staphylococcus aureus Vibrio cholerae Daniel Nogueira 112
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Vibrio parahaemolyticus Vibrio vulnificus Yersinia enterocolitica Yersinia pseudotuberculosis Vírus Hepatite A Norovirus Rotavírus Protozoários Giardia lamblia Toxoplasma gondii Cryptosporidium spp. Alimentos suspeitos a)Ingestão do alimento xxxx, n dias antes do aparecimento dos sintomas b) Alimento suspeito analisado? Local de ingestão do alimento contaminado? Outras pessoas apresentaram a mesma sintomatologia? Daniel Nogueira 113
    • PROTOREG – Programa piloto de registo de intoxicações alimentares ANEXO 3 A classe e as funções apresentadas a seguir foram desenvolvidas para tratar strings com código html em que as últimas tags não são fechadas. Daniel Nogueira 114
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Daniel Nogueira 115
    • PROTOREG – Programa piloto de registo de intoxicações alimentares Daniel Nogueira 116