Eventster
From Laboratório MM 5
(→Base de Dados Relacional) |
(→2.Base de dados desenvolvida) |
||
| Line 36: | Line 36: | ||
===2.Base de dados desenvolvida === | ===2.Base de dados desenvolvida === | ||
| - | + | Esta é a imagem da base de dados: | |
| - | |||
| - | |||
| - | + | 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. | ||
===Implementação da aplicação=== | ===Implementação da aplicação=== | ||
Revision as of 06:07, 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
Esta é a imagem da base de dados:
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.
Implementação da aplicação
- Descrição das principais funcionalidades da aplicação Web
As principais funcionalidades da nossa aplicação web são:
- Registo - O utilizador pode registar-se no site através de um formulário básico. Os campos são todos de preenchimento obrigatório.
- Login – Após o registo, o utilizador pode fazer login na aplicação e obter acesso às páginas de acesso restrito.
- Logout - Permite que o utilizador termine a sessão iniciada.
1. Recordsets:
Foram desenvolvidos (x) Recordsets:
2. Server behaviours:
Log In User – permite realizar o login do utilizador.
Log out user- permite realizar o logout do utilizador
Repeat region- usado para repetir elementos vindos da base de dados, nomeadamente, listas criadas como resultados de pesquisas.
3. Queries:
(por adicionar)
4. Parâmetros passados entre páginas:
Os parâmetros passados entre páginas foram feitos pelos métodos get e post.
GET:
- Resultados da pesquisa de eventos e utilizadores.
POST:
- Parâmetros de username e password
- Variáveis de sessão
- Integração
O layout do site foi desenvolvido com o uso de formatações através de CSS.
Sugestões de Desenvolvimento
Devido a constrangimentos de recursos, tempo e conhecimento, muitas das ideias iniciais foram abandonadas. No entanto gostaríamos de ter implementado:
1 - Integração com GoogleMaps;
2 - Sistema de localização de festas numa área a "x" distância do utilizador;
3 - Partilha de fotografias/vídeos por parte dos utilizadores;
4 - Sistema de notificação via e-mail.
Conclusões
Apesar do produto final ter ficado muito aquém das nossas expectativas, pensamos que o conceito da aplicação tem potencial para o sucesso. Temos consciência de que o mesmo não está completamente funcional, devido a problemas que nos ultrapassam e falta de meios, tempo e conhecimento, sendo que o produto final se assemelha mais a um protótipo/prova de conceito do que a um produto comercial.
