Collectableskeeper
From Laboratório MM 5
Contents |
Elementos
- Daniel Ferreira da Silva - 49490
- Luís Filipe Brasil de Melo - 49722
- João Paulo Medeiros Costa - 50011
- Marina Sofia Ferreira da Silva - 50766
Agradecimentos
Não podíamos concluir definitivamente este projecto sem antes agradecer a todos os intervenientes que permitiram que o desenvolvimento do Collectables Keeper fosse possível. Por isso, agradecemos o apoio de todos os docentes de Laboratório Multimédia V: Hélder Caixinha, Licínio Mano e Nuno Ribeiro. Agradecemos também a ajuda no teste e avaliação da aplicação por parte de Paulo Melo.
Introdução
O presente documento surge no contexto curricular da disciplina de Laboratório Multimédia V, da licenciatura de Novas Tecnologias da Comunicação da Universidade de Aveiro. A estrutura deste é composta por 6 secções que elucidam o leitor acerca do desenvolvimento do projecto Collections Keeper – a introdução, onde se verifica o objectivo do relatório; a visão geral do projecto, que constitui a definição do projecto; o design gráfico; a base de dados, onde se valida as relações entre as várias informações que o projecto requisita; a implementação que engloba a descrição das principais funcionalidades da aplicação, o mapa de páginas e a integração entre as tecnologias utilizadas; os desenvolvimentos futuros, onde se permite informar possíveis melhorias ou evoluções no projecto; as conclusões, que resumem a opinião dos membros ao desenvolvimento do projecto; e as referências bibliográficas, que apresentam as fontes que serviram de suporte e apoio na concretização do mesmo.
Objectivo do documento
Este relatório permite dar a conhecer toda a ideia conceptual do projecto, esclarecendo assim o propósito deste, tendo, obviamente em conta os conhecimentos adquiridos nas aulas e todo um processo autodidacta. Também se tomará atenção aos detalhes do design gráfico e o desenvolvimento técnico, que vai desde a criação e implementação de uma base de dados até ao recurso a várias tecnologias como PHP, CSS, HTML, MySQL, Ajax, entre outros. Também neste âmbito é importante realçar os problemas consequentes e as respectivas soluções. Após o desenvolvimento do projecto efectuou-se, portanto, uma análise do mesmo e considerações a futuras melhorias.
Visão geral do Projecto
O presente projecto designa-se “Collectables Keeper” e consiste na criação de um website baseado numa espécie de caderneta virtual, em que o utilizador poderá catalogar os seus objectos de colecções, estes já existentes fisicamente, de uma ou várias categorias. Assim, de forma a completar a sua colecção poderá comprar produtos a outros utilizadores ou até mesmo a marcas que disponibilizem no site os seus produtos. O valor do produto pode sofrer alterações na medida em que os pontos do utilizador podem ser trocados por descontos nestas compras. Os pontos são acumulados de acordo com o número de logins diários e o valor das compras que o utilizador efectua, ou seja, quantos mais euros gastar, mais pontos terá. Os utilizadores premium terão, como bonificações, o dobro de pontos nas acções anunciadas anteriormente. Também terão a vantagem de ter acesso à colecção da empresa (merchandising), cujos objectos só podem ser adquiridos por pontos. Outra diferença entre o utilizador normal e o premium é que o primeiro estará condicionado a possuir um máximo de duas colecções, enquanto que o segundo não terá qualquer limite. Em relação aos administradores/empresa, estes terão uma comissão (10%) sobre as transacções efectuadas. No que diz respeito ao público-alvo, procurámos uma aplicação que não condicionasse nenhum indivíduo pela sua idade, classe social ou até mesmo cultura. Desta forma, este projecto é orientado a todas as pessoas de todas as faixas etárias e de todas as classes sociais, podendo utilizar este sistema como um acessório de organização aos bens que possui. Porém, não podemos descurar a característica fundamental da WEB 2.0: a interacção entre utilizadores, em que o utilizador é o protagonista de toda a acção da aplicação. É neste contexto que o projecto também responde a estas necessidades, permitindo a interacção entre os vários coleccionadores de forma a que eles tenham uma “voz”, através do rating aos itens e colecções e comentários a estes, incluindo ainda as transacções.
Design gráfico
O conceito de coleccionador remonta para a conservação de algo ao longo do tempo, ou seja, a estima pelo produto ao longo do tempo é o que é mais valorizado nesta área. Assim decidimos recorrer ao estilo retro, visto que transmite uma sensação de nostalgia do passado, da mesma forma que esta é uma das sensações despoletadas pelos objectos de colecção. A escolha das cores do projecto recaíram para uma vertente mais clássica mas tentando ser ao mesmo tempo apelativa aos mais jovens, para que possa agradar a maioria dos futuros utilizadores. O fundo texturizado em tons de cinzentos enquadra-se numa direcção mais formal, enquanto que os tons de verde pretendem avivar, evitando uma interface demasiado escura e sombria. A utilização de um marcador, como é o caso da fita verde que se encontra no lado esquerdo da interface durante toda a navegação, realça a ideia geral e intuito deste projecto. Isto é, enfatiza o facto de querermos que o Collectables Keeper seja uma espécie de caderneta virtual para os coleccionadores onde o marcador está sempre presente e é fácil de encontrar o local exacto onde colocar os seus coleccionáveis. No que diz respeito ao logótipo, e tendo ainda em conta o estilo retro, optamos por uma espécie de carimbo, como se fosse uma aprovação ao próprio projecto e àquilo que ele representa.
Base de dados
Para o correcto funcionamento deste projecto, e aplicando os conhecimentos adquiridos na unidade curricular, foi crucial a criação de uma base de dados relacional, e respectiva implementação. Toda a informação do nosso site é armazenada na base dados, sendo esta constituída pelas seguintes tabelas:
ck_utilizador – toda a informação, desde dados pessoais até aos dados resultantes da interacção do utilizador com o website.
ck_utilizadorFavorito – armazena os pares de utilizadores, em que um adiciona o outro como favorito.
ck_notificacao - conserva todos os dados que constituem as notificações que os utilizadores recebem quando surge informação relacionada com os mesmos, como por exemplo comentários aos nossos itens, alguém que seguimos adiciona uma colecção.
ck_comentario - contém tudo o que está relacionado com o comentário, não só o texto escrito mas também o registo do autor, data, tipo, etc.
ck_denuncia – quando um utilizador faz uma denuncia, é aqui que essa informação fica registada. Abrange a identificação do autor, a data, o objecto e o valor da denúncia.
ck_item – suporta todos os dados relacionados com o item, essenciais para quando o utilizador faz o registo de um item: nome, descrição, imagem, e colecção a que pertence.
ck_coleccao – inclui todos os dados relacionados com a colecção, tabela esta crucial para este projecto. Inclui o nome, a descrição, imagem, utilizador que a detém e a classe a que pertence.
ck_coleccaoFavorita – armazena os dados da relação que liga o utilizador que adiciona uma colecção como favorita.
ck_rating – a informação da acção de rating, que pode ser tanto para um item como para uma colecção, é armazenada de forma geral, isto é, não existe diferenciação entre o tipo de objecto pois a atribuição do rating é feita de igual forma para ambas as situações e a tabela ck_tipoObjecto surge como facilitadora para a identificação do objecto em causa.
ck_itemVenda – tendo em conta que um item de venda tem uma constituição diferente dos outros itens que fazem parte das diversas colecções, este inclui ainda informação extra como stock, preço, classe, data de colocação à venda e utilizador.
ck_transaccoes – na parte das vendas do nosso site é fundamental o armazenamento de dados das transacções tanto para o utilizador como para os administradores. Inclui dados como a identificação do utilizador que coloca a venda e o que compra, a data da compra, os pontos gastos, preço final da compra e rating da transacção.
Para complemento das outras tabelas, foi necessário criar tabelas que servem de catálogos de informação. Estas são: ck_pais, ck_classe, ck_tipoUtilizador, ck_tipoObjecto.
Implementação
URL Rewriting
De modo a tornar as hiperligações das várias páginas mais amigáveis quer para o utilizador, quer em termos de SEO, interessou-nos a ideia de reescrever as hiperligações. Utiliza-mos para isso o módulo do Apache denominado URL Rewriting que nos permite através do uso de expressões regulares reescrever o URL de uma página mantendo ao mesmo tempo os parâmetros passados utilizando o método GET.
Exemplo:
http://collectableskeeper.co.cc/?webPage=user&idArg=luismelo91 foi reescrito para http://collectableskeeper.co.cc/user/luismelo91 tornando-se de muito mais fácil memorização, bem como bookmarking. Isto levanta um problema, pois todas as hiperligações do site eram reescritas, sendo que tivemos que tornar as mesmas absolutas.
OOP – Object Oriented Programing
Para facilitar a gestão de todos os objectos que fazem parte da aplicação e para aprofundar o nosso conhecimento sobre a OOP, decidimos criar um conjunto de classes por forma a manter organizada toda a informação relacionada com cada um dos objectos. Criamos assim as seguintes classes:
Collection.class.php – guarda todos os dados relacionados com a colecção, como o nome, o id do dono... e permite obter um array contendo os itens que essa colecção possui.
Comment.class.php – dados relacionados com os comentários
Iten.class.php – dados relacionados com os itens
Itensell.class.php – dados relacionados com os itens para venda
Notification.class.php - dados relacionados com as notificações
Report.class.php - dados relacionados com as denúncias
Transaction.class.php - dados relacionados com as transacções
User.class.php – contém todos os dados relacionados com o utilizador e interage com as outras classes, permitindo por exemplo obter as colecções do utilizador, as notificações, transacções...
ReadDb.class.php e writeDb.class.php – possuem um conjunto de procedimentos e métodos que visam simplificar as interacções com a base de dados, sendo que a writeDb tem o suporte para transacções do MySQL protegendo assim a integridade dos dados.
Páginas erro 403 e 404
Os erros ocorridos devido a por exemplo inexistência de ficheiros podem expor informações que podem comprometer a segurança do servidor. Para evitar esse problema e para apresentar ao utilizador uma página de erro mais amigável, decidimos criar versões alternativas para estes erros tendo a conta a estrutura e apresentação geral do website. Integração com carteira online (Paypal) Para o total funcionamento do website é necessário que o utilizador disponha de fundos para poder adquirir um tipo de conta premium ou para efectuar compras na secção das vendas. Torna-se assim necessário uma forma que permite depositar e levantar fundos da conta do utilizador. De todas as opções disponíveis no mercado, optámos pelo Paypal uma vez que oferece APIs de fácil utilização e integração com o PHP. O depósito de fundos é efectuado com recurso a um botão de pagamento fornecido pelo Paypal. Após clicar no botão, o utilizador é redireccionado para a página do Paypal onde efectua o pagamento (neste caso do valor predefinido para o depósito). Após o pagamento, o Paypal envia um “Instant Payment Notification” para um ficheiro alojado no nosso servidor, o qual verifica a integridade dos dados e actualiza a conta do utilizador com os fundos depositados. O levantamento de fundos já requereu outro tipo de abordagem. Aqui foi utilizada a API do “Mass Payment” fornecida pelo Paypal. Esta API, após fornecidos os dados necessários (username, password e apisignature) efectua um pagamento directo para o e-mail que o utilizador forneceu no formulário de levantamento.
Descrição das principais funcionalidades da aplicação web
Registo - o utilizador através de um formulário pode registar-se no website e ter acesso a conteúdo e funcionalidades mais restritas ao utilizador não registado. O formulário é alvo de verificações tanto a nível de Javascript como de PHP em que são revistos os dados que o utilizador inseriu de acordo com os requisitos definidos nestas duas línguas de programação.
Login – este só pode ser realizado pelos utilizadores que se registaram previamente. Após colocar os dados de acesso (username e password), o utilizador é transportado para a página do seu perfil. Este foi implementado com o recurso à classe user que possui uma função específica para a validação dos dados de login, devolvendo true ou false. Caso seja true (o utilizador existe), este é construído através da mesma classe, sendo posteriormente iniciada a sessão e as respectivas variáveis. Caso seja false (o utilizador não existe) acontece um recarregamento da página principal, surgindo uma mensagem de erro de login.
Logout – para que o logout ocorra, e após o utilizador clicar no respectivo botão, este é redireccionado para a página principal, transportando uma querie string com a acção logout.
Criação/Edição do Perfil - é permitido ao utilizador introduzir e modificar os dados do seu perfil, tendo em conta que estes estarão visíveis aos outros utilizadores registados.
Criação/Edição/Eliminação de Colecções e Itens - ainda na página de perfil, é possível a criação de novas colecções e respectivos itens em que o utilizador insere a informação essencial para identificar estes mesmos objectos através de um formulário de submissão. Também é permitido ao utilizador inserir novos itens que este pretende colocar à venda através do preenchimento do formulário de submissão onde são definidas as informações do item, bem como o seu preço e a quantidade disponível para venda. No perfil o utilizador tem a possibilidade de remover os objectos que lhe pertencem bem como editá-los através do ícone correspondente.
Colecções/Itens – nesta página é visível o conjunto de colecções, em que cada uma contém um ou mais itens, adicionadas por todos os utilizadores. O utilizador numa primeira fase visualiza apenas a colecção mas após clicar nesta surgirá todos os itens que a constituem.
Rating - o utilizador, ao longo da navegação na aplicação pode efectuar o rating em colecções, itens (excepto nos itens de venda) e transacções. Caso o rating já tenha sido feito anteriormente, este será substituído pela nova submissão. A submissão desta funcionalidade é feita através de Ajax de modo a evitar o novo carregamento da página.
Denúncia – o utilizador registado pode fazer a denúncia das colecções e itens que não pertencem ao próprio utilizador em sessão. Por forma a evitar um possível abuso desta funcionalidade, definimos um limite de uma denúncia por dia e por utilizador.
Adicionar Colecções e Utilizadores Favoritos – aqui procurou-se manter este processo de uma forma diferente ao que é usual se ver em aplicações onde o conceito seja uma comunidade virtual. Assim, para acrescentar colecções e utilizadores favoritos, o utilizador apenas necessita de clicar num botão que se encontra no cimo da imagem da colecção e arrastar para a imagem do utilizador que tem a sessão iniciada, que se encontra no canto superior direito. Esta é uma funcionalidade que traz uma maior interactividade com o utilizador e para a implementar recorremos ao JQueryUserInterface.
Pesquisar – esta funcionalidade está presente em toda a navegação do site, sendo que, dependendo do menu onde se encontre o utilizador, a pesquisa é orientada para a informação dessa página, isto é, se estiver na Home ou nas Colecções a pesquisa é feita sobre as colecções, caso seja a das Vendas é feita sobre os itens à venda.
Vendas – o utilizador tem a possibilidade de colocar à venda itens que já não queira, acrescentando-os na secção das vendas do site, que podem ser adquiridos por outros utilizadores. A compra destes itens tem em conta como factores importantes o preço (existe também um filtro dedicado ao preço) e os pontos acumulados pelo utilizador. Estes últimos têm papel fundamental na compra de itens de merchandising e nos benefícios especiais para os utilizadores premium.
Contactar os administradores através do formulário presente no fundo da imagem em todas as páginas – Para que seja mais acessível e esteja sempre presente a opção de contactar os administradores, resolvemos colocar um formulário que se encontra sempre disponível no footer.
Mapa de páginas
charge.php – possui os formulários para levantar e depositar fundos e subscrição de conta premium
collections.php – possui a lista de todas as colecções existentes onde é possível fazer as filtragens e ordenações
collection.php – página dos detalhes da colecção páginas para editar colecção, utilizador, item e item venda
home.php – possui o conteúdo da página principal
index.php – utilizado para efeitos de suporte a URL Rewriting
merchandising.php – possui a lista de itens de merchandising
profile.php – contém o perfil do utilizador autenticado
user.php – perfil de um utilizador
regist.php – permite efectuar o registo do utilizador
sells.php – lista de itens para venda
Server behaviours e recordsets/queries utilizados
Como falado anteriormente, este projecto foi desenvolvido sobretudo a partir de classes, sendo que desta forma não existem server behaviours e recordsets predefinidos. A grande maioria está definida dentro das classes, em que são usados os métodos dessas classes para obter os valores pretendidos, por exemplo a classe utilizador permite-nos obter as transacções desse utilizador (array de objectos transaction). Foram no entanto utilizadas queries para efectuar por exemplo a ordenação e a filtragem na página de vendas. Esta query era construída consoante os parâmetros que o utilizador definia e a partir dos ids obtidos na query eram construídos e guardados num array os itens para venda que depois através de um ciclo eram apresentados na página utilizando os vários métodos e procedimentos proporcionados pela classe dos itens de venda. Um outro ponto que merece destaque refere-se à solução adoptada para conseguir apresentar as colecções ordenadas por rating. Não existe qualquer tipo de ligação entre a tabela de colecções e a tabela rating, uma vez que esta guarda todos os ratings efectuados aos vários tipos de objectos existentes (colecção e item) e não seria possível ligar as tabelas uma vez que seria violada a integridade referencial, ou seja, o id do objecto sobre o qual foi feito o rating, pode ser uma colecção ou um item e se as tabelas estivessem ligadas, iria causar problemas, uma vez que um dos dois objectos pode não existir. Para resolver este problema recorreu-se à criação de uma View através de uma query que ligasse todas as tabelas necessárias utilizando queries inclusivas e exclusivas.
SELECT idColeccao, nomeColeccao, 0 ratingColeccao, classeId, valorClasse, username
FROM ck_coleccao
INNER JOIN ck_classe ON
classeId = idClasse
INNER JOIN ck_utilizador ON ck_coleccao.utilizadorId = ck_utilizador.idUtilizador
WHERE estadoColeccao = 1 AND idColeccao NOT IN (SELECT objectoRating FROM ck_rating WHERE tipoRating = 2)
UNION
SELECT idColeccao, nomeColeccao, AVG(valorRating) ratingColeccao, classeId, valorClasse, username
FROM ck_rating, ck_coleccao
INNER JOIN ck_classe ON classeId = idClasse
INNER JOIN ck_utilizador ON ck_coleccao.utilizadorId = ck_utilizador.idUtilizador
WHERE estadoColeccao = 1 AND idColeccao = objectoRating AND tipoRating = 2
GROUP BY idColeccao
ORDER BY ratingColeccao DESC, nomeColeccao ASC
Parâmetros passados entre páginas
As possíveis formas de passar parâmetros entre páginas são o método GET, o POST e SESSÃO. Através do método GET são passados os parâmetros respectivos:
- As mensagens de sucesso e erro (feedback) das várias acções possíveis
- Os valores correspondentes ao ID dos itens, colecções, itens para venda e itens de merchandising
- Valores correspondentes ao username dos utilizadores
- Identificar o tipo de página que estou a aceder (página de colecções, itens, itens de venda...).
- Valores provenientes do campo de pesquisa
- Forma de ordenação do conteúdo das páginas
- Todas as acções que incluem eliminar itens, colecções, utilizadores ou itens para venda. São passados o ID desses objectos e o tipo de objecto a eliminar
- O valor mínimo e máximo correspondente ao filtro de preço.
Através do método POST são passados os parâmetros respectivos:
- Às acções possíveis de efectuar e os respectivos dados referentes ao rating, adicionar aos favoritos ou efectuar uma denúncia. Apesar de ser por POST, é utilizada a tecnologia AJAX
- O valor dos vários formulários, como é o caso do formulário de contacto presente no footer em todas as páginas, ou o formulário de adicionar colecções, adicionar itens...
Através do método SESSÃO são passados os parâmetros respectivos:
- O id de quem efectuou o login para verificar se este está realmente autenticado
- Valores essenciais para garantir que o upload de imagens para item, colecção, perfil e item venda está a ser efectuado correctamente
- No caso do utilizador ser administrador e querer apagar um utilizador, colecção, item ou item venda é necessário garantir que o id do dono do objecto que o administrador pretende apagar é o correcto. Sendo assim esse id é guardado numa variável de sessão quando o administrador entra numa das páginas dos objectos que é possível apagar.
