Eventster
From Laboratório MM 5
(→2.Base de dados desenvolvida) |
|||
| Line 109: | Line 109: | ||
Os principais Recordsets e query's são: | Os principais Recordsets e query's são: | ||
| - | * | + | * '''rs_todos_eventos:''' devolve todos os campos presentes na tabela" eventos" que serve para preencher uma "repeat region"; |
| + | *''' rs_perfil:''' devolve todos os campos presentes na tabela utilizador correspondentes ao utilizador numa determinada sessão; | ||
| + | * '''rs_meus_eventos:''' devolve todos os parametros da tabela eventos correspondente a um determinado utilizador que serão posteriormente utilizadas para preencher uma repeat region; | ||
* | * | ||
Revision as of 08:30, 2 February 2012
Contents |
Composição do Grupo
- Joana Flora - 45716
1.Introdução
Introdução Este relatório foi realizado no âmbito da Unidade Curricular de Laboratório Multimédia 5, leccionada no 1º semestre do 3º ano do curso de Novas Tecnologias da Comunicação da Universidade de Aveiro. É uma forma mais rápida e sucinta de explicar o desenvolvimento do projecto que foi proposto implementar para a época de recurso.
1.1 Objectivo do documento
Objectivo do documento O objectivo principal deste documento incide em relatar grande parte do processo de criação e desenvolvimento do projecto proposto.
A proposta era:
- Criar uma plataforma 2.0;
- utilizar as tecnologias leccionadas.
Para que fosse possível concretizar o projecto, foi implementada uma base de dados, foi ainda estruturar toda a informação a implementar (em PHP, CSS, HTML) bem como criar um layout. Posteriormente serão explicados estes processos, e serão ainda apresentadas propostas de melhoria para enriquecer um possível produto final.
1.2 Visão geral do projecto
Visão geral do projecto A Web 2.0 é conhecida pela sua dinâmica no que diz respeito ao uso da Web (internet), dinâmica essa que permite aos utilizadores a interacção entre si e participação efectiva na Web ou seja o utilizador hoje em dia não se limita apenas a ser espectador como em outros tempos, actualmente o utilizador também assume o papel de produtor / editor de conteúdos.
Foi com os olhos postos no que é a web2.0 que o meu grupo de trabalho anterior(época normal) e após terem surgido diversas ideias e todas elas incidiam em “Como é viver em Aveiro?” e as dificuldades que os estudantes e não só encontram ao chegar à cidade, e apercebemo-nos de potenciais plataformas que poderiam resultar para os jovens que passam por Aveiro. Mas após alguma reflexão, a ideia que acabou por prevalecer foi a criação de uma Agenda Cultural que permitisse aos jovens de Aveiro e não só (estudantes / não estudantes) saberem o que se andava a passar no distrito de Aveiro e quem sabe procurar o que se anda a ocorrer noutros distritos, quer a nível de workshops, actividades de diversão nocturna, convívios, festas, concursos, etc. porque muita dessa informação acaba por passar-nos ao lado e quando chega muitas vezes já não está actualizada. Para que plataforma funcionasse devidamente os utilizadores teriam de criar uma conta (comum/premmium) onde seria possível ver os eventos publicados por ele e por outros utilizadores, poderia editar/apagar os eventos que tivessem sido postados por ele, criar novos eventos, comentar os eventos, e poderia visualizar geograficamente através do Google Maps o local onde iria decorrer o evento e ainda poderia trocar mensagens “privadas” com o criador desse mesmo evento. Os utilizadores não registados apenas poderiam ver a informação publicada. Nos detalhes dos eventos seriam fornecidas informações como a localização gráfica dos eventos (através do Google maps) bem como informações de quem criou o evento, hora a que decorre o evento e os pormenores relativos a esse mesmo evento. A inserção de “Amigos” do utilizador poderia ser através de um faceboock connect, para que o utilizador pudesse partilhar com os seus amigos, eventos criados por si ou eventos em que fosse participar, ajudando assim a espalhar a informação que evento “X” irá acontecer em determinado local. Quanto ao Layout que foi pensado em grupo ira ter cores sóbrias (preto e verde) e teria um aspecto bastante sofisticado, mas quando chegou a hora de implementar o projecto individualmente, decidi que o projecto teria de ter uma imagem mais simples do que gostaria porque o tempo para trabalhar no layout e implementar o projecto era muito curto. Ainda assim como a aplicação é para jovens, acabei por fazer um banner simples mas mais colorido para dar um ar mais divertido à página. Apesar do layout não ser elaborado está funcional.
2.Base de dados desenvolvida
Link imagem da base de dados:[1]
A base de dados do projecto Eventster foi criada para desenvolver os requisitos mínimos “exigidos” para recurso, uma vez que a base de dados anteriormente implementada em grupo tinha alguns problemas. Esta base de dados foi construída no MySQL Workbench e tem 8 tabelas.
- A tabela “Eventos” é responsável por guarda toda a informação relativa eventos criados e os dados guardados são: o utilizador que criou o evento, o titulo do evento, a descrição do evento, a data e hora em que decorrerá o evento, a categoria a que pertence o evento, o local que é apresentado com url do Google Maps e o distrito onde ocorrerá o acontecimento.
- “Categorias” esta tabela foi criada para que através de um menu dropdown o utilizador possa escolher a categoria em que se insere o evento que pretende publicar.
- A tabela "Distrito" está presente porque pensei que os eventos apresentados na página de eventos podem decorrer em outros distritos do interesse dos utilizadores de Aveiro.
- Na tabela “Utilizador” é guardada toda a informação referente aos utilizadores registados. A informação guardada é: o nome, morada, localidade, distrito, nº de telefone, data de nascimento, correio electrónico, o tipo de utilizador, username, password, pergunta secreta, resposta secreta, data e hora do registo, data e hora do ultimo login. Esta tabela encontra-se interligada a grande parte das tabelas existentes na base de dados excepto à de "Categorias" e à de "Eventos" A tabela
- “ Comentários” esta tabela está encarregue de alojar toda a informação referente aos comentários efectuados e para que tal seja possível ela guarda os seguintes campos: o "id" dos comentários, os eventos que foram comentados, qual dos utilizadores efectuo o comentário e a data e hora em que foi submetido o comentário.
- A tabela “Mensagens” guarda as mensagens "privadas" trocadas entre os diferentes utilizadores registados da plataforma e abriga os seguintes campos: o "id" da mensagem, o utilizador que a enviou (emissor), o utilizador que irá receber a mensagem (receptor), guarda ainda o assunto, o corpo e a data e hora a que a mensagem foi enviada.
- “Distrito” esta tabela tal como a tabela de Categorias serve para facilitar a inserção de dados por parte do utilizador evitando erros (ortográficos, entre outros) do mesmo.
- “Tipo de utilizador” esta tabela serve para limitar o tipo de utilizadores, podendo ser utilizadores comuns (registados) ou Premium.
- A tabela de “Pergunta de segurança” serve como método de segurança, porque caso o utilizador se esqueça da password terá de contactar o admin do site para que lhe possa ser atribuída uma nova password e a pergunta secreta será uma das formas de despiste para eventuais fraudes.
3. Implementação
3.1 Descrição das principais funcionalidades da aplicação Web
A plataforma “Eventster” admite que todos os visitantes, registados ou não, possam ver os eventos submetidos pelos utilizadores registados, organizados por data e hora de submissão, ainda existe a possibilidade de ser efectuada uma pesquisa por palavra-chave para poder aceder a um determinado evento ou conjunto de eventos consoante as preferências utilizador.
Caso tenha dificuldades na "navegar" na aplicação, o visitante pode consultar a página de FAQ (Frequently Asked Questions), e observar uma pequena lista das perguntas mais frequentes sobre a plataforma e os esclarecimentos. Também pode encontrar nesta pagina o contactos da equipa de desenvolvimento (neste caso eu).
É possível registar-se na própria plataforma, através do preenchimento de um simples formulário, em que basta preencher os campos obrigatórios para efectuar o registo com sucesso. Depois de ter submetido o formulário de registo, o utilizador pode/deve fazer login (que permite a entrar na aplicação Web com os seus dados) e logout (sair da aplicação Web depois de efectuado o Login). Os utilizadores registados têm ao seu dispor o seu próprio perfil com os seus dados pessoais que podem ser editados pelo utilizador sempre que este o pretenda fazer.
Quando o utilizador se encontrar Logado terá à sua disposição as seguintes funcionalidades:
- Ver/comentar/editar/apagar os eventos criados por si.
- Criar novos eventos.
- Ver/comentar eventos criados por outros utilizadores.
- Enviar/ receber/apagar mensagens ”sigilosas”.
3.2 Mapa de páginas
link mapa_site:[2]
3.2.1 Server Behaviours utilizados
No decorrer da implementação foram usados vários Server Behaviours entre os quais:
- Insert Record – foi utilizado para inserir dados na BD, ao efectuar o registo de utilizadores, ao escrever novas mensagens e ao criar novos eventos, por exemplo
- Update Record – utilizado para actualizar os dados anteriormente inseridos ("Meu Perfil", "Editar Evento", etc)
- Dynamic Text - apresenta os dados alojados na BD
- Repeat Region – foi utilizado em algumas páginas para repetir determinados fragmentos de código / conjuntos de dados, sobretudo na página de Eventos, na de Comentários, mensagens recebidas entre outras.
- Restrict Access To Page – foi utilizado para fazer a gestão de sessões porque torna o acesso restrito a determinados utilizadores. Por exemplo apenas os utilizadores registados podem publicar eventos.
3.2.2 Recordsets/Queries utilizados
Para poder carregar, inserir e editar os dados existentes na Base de dados do projecto, foram efectuados vários Recordsets e consequentemente várias queries que facultaram a informação necessária para a implementação.
Os principais Recordsets e query's são:
- rs_todos_eventos: devolve todos os campos presentes na tabela" eventos" que serve para preencher uma "repeat region";
- rs_perfil: devolve todos os campos presentes na tabela utilizador correspondentes ao utilizador numa determinada sessão;
- rs_meus_eventos: devolve todos os parametros da tabela eventos correspondente a um determinado utilizador que serão posteriormente utilizadas para preencher uma repeat region;
- rs_meus_eventos - vais buscar à tabela parâmetros para poder preencher o formulário de adicionar evento.
3.2.3 Parâmetros passados entre páginas
Para poder passar parâmetros entre as páginas, teve de utilizar-se os métodos de GET, POST, por url, e através da Session, ou seja, para que através do id que o utilizador que tem, no momento, percebermos se a sessão está iniciada ou não.
O método GET foi utilizado para ir buscar o conteúdo de um parâmetro resolt.
O método de POST foi sobretudo utilizado, no preenchimento de formulários, como o de efectuar registo.
Para conseguir perceber qual dos utilizadores fez login assim poder carregar os seus dados foi utilizado o parâmetro de Session "MM_Username", que corresponde ao username.
3.3 Integração
Para além de utilizar PHP, que foi a linguagem essencial para desenvolver os conteúdos dinâmicos nas páginas, foram ainda utilizadas outras linguagens frequentes no desenvolvimento de produtos para web tais como:
- Html – foi utilizado para estruturar todas as páginas existentes na plataforma.
- Css – O Css foi utilizado para formatar os conteúdos dos ficheiros externos.
4. Desenvolvimentos Futuros
Uma vez que não foi possível concluir o projecto como ele foi idealizado, e como muito do que era suposto estar implementado nesta plataforma ficou aquém das expectativas, gostaria ainda assim de ver alguns módulos implementados futuramente como por exemplo um sistema de mensagens mais robusto e complexo. Também gostaria de ver um sistema de chat onde os utilizadores pudessem trocar impressões sobre os eventos em tempo real. A questão da inserção do Google maps no corpo do evento sem ser necessário estar a ir buscar o URL ao Google maps e colar no campo correspondente da plataforma, aprimorar mais o Layout.
Conclusões
Apesar das minhas limitações como programadora, gostei de efectuar este desafio da Unidade Curricular de Laboratório Multimédia V uma vez que me ajudou a perceber um pouco melhor as potencialidades do php. Para conseguir implementar a plataforma tive de efectuar muita pesquisa on-line, e tive mesmo de recorrer a colegas para me auxiliarem a perceber certos mecanismos e poder implementar os conteúdos da forma mais correcta possível. Ainda assim tentei ao máximo ultrapassar as minhas dificuldades e por à prova os meus conhecimentos relativos ao que foi dado em ambiente de aula.
Bibliografia
- CAIXINHA, Hélder & MANO, Lícinio – slides das Aulas teóricas e práticas de Laboratório Multimédia 5, 2011/2012
