Coordenador de uma equipa

O coordenador nomeado, seja o pr´oprio diretor do clube ou outro utilizador, tem o poder para editar a informa¸c˜ao da equipa que coordena e adicionar jogadores ou editar os jogadores j´a existentes nessa equipa.

Para criar um jogador o utilizador ter´a de aceder `a p´agina respetiva (Figura 4.28), onde ser´a pedido que insira os dados necess´arios relativos ao jogador que quer inserir. Esses dados s˜ao o nome, o n´umero de camisola, a data de nascimento e o n´umero do cart˜ao de cidad˜ao.

Figura 4.29: P´agina de cria¸c˜ao de um jogador

4.1.5 Extras

Calend´ario de jogos edit´avel

Existe uma sec¸c˜ao destinada `a apresenta¸c˜ao dos jogos distribu´ıdos pelos dias definidos para o torneio (Figura 4.30). Para ajudar na sua apresenta¸c˜ao, foi implementado um calend´ario com recurso ao fullcalendar [24], onde s˜ao distribu´ıdos os jogos do torneio. Para al´em de poder ser usado como fonte de consulta, ´e tamb´em aqui que o organizador pode alterar as datas e dias dos jogos, simplesmente arrastando a caixa destinada a esse jogo para a data e hora pretendida.

Figura 4.30: Distribui¸c˜ao dos jogos no calend´ario

Caixa de pesquisa

Foi adicionada uma caixa de pesquisa que poder´a ser usada por todos os utilizadores, para procurar em todo o sistema por clubes, equipas, jogadores ou utilizadores. A figura 4.31 demonstra a apresenta¸c˜ao dos resultados para uma pesquisa.

Figura 4.31: Exemplo de pesquisa

Para implementar esta pesquisa foi usada a fun¸c˜ao search do controlador HomeController, que realiza as querys necess´arias `a base de dados para obter todos os dados que se encaixam na palavra pesquisada, passando-os, depois, em JSON[31], para a view, onde a informa¸c˜ao ser´a apresentada utilizando como base o c´odigo presente na documenta¸c˜ao do jqueryui [32].

Edic¸˜ao do regulamento e do convite

Quando ´e criado um torneio, s˜ao gerados automaticamente o regulamento e o convite

com base na informa¸c˜ao de cada torneio. No entanto, o organizador pode ver e alterar estes ficheiros utilizando a plataforma (Figura 4.32). Desta forma, o organizador do torneio poder´a

adaptar tanto o convite que ser´a enviado aos clubes, como o regulamento do torneio a seu gosto. Estes podem ser mais tarde descarregados em formato PDF atrav´es do uso do conversor de HTML para PDF [26].

Figura 4.32: Regulamento edit´avel

Para gerar a caixa de edi¸c˜ao foi utilizado o editor tinymce[33], para edi¸c˜ao em web de texto HTML.

Caso n˜ao exista um regulamento modificado anteriormente, ´e carregado no editor um re-

gulamento gerado com base num template. Depois de modificado, o regulamento ´e guardado

novamente e, na vez seguinte, ser´a este o regulamento carregado. Este ficheiro ´e guardado num ficheiro com extens˜ao HTML na pasta respetiva, sendo que cada torneio ter´a uma pasta destinada apenas aos seus ficheiros.

O m´etodo de funcionamento para os convites ´e semelhante.

Upload de ficheiros extra

Para facilitar a partilha de informa¸c˜ao entre os intervenientes num torneio, foi implemen- tado um sistema de armazenamento de ficheiros, em que ´e permitido ao organizador guardar na base de dados ficheiros com informa¸c˜ao referente ao torneio. ´E feito o upload do ficheiro e guardado o seu caminho na base de dados.

Na figura 4.33 ´e apresentada a interface oferecida para realizar o upload, assim como os ficheiros j´a inseridos, neste caso apenas um. Todos os ficheiros inseridos para al´em dos j´a gerados (Regulamento e Convite), s˜ao identificados como ficheiros Extra. Posteriormente ´e permitido a qualquer utilizador visualiz´a-los e ao organizador apaga-los.

Figura 4.33: Upload de ficheiros

Cada torneio tem no servidor uma pasta destinada aos seus ficheiros ficheiros, sendo guardado o caminho para cada um na base de dados.

Barra informativa

Para facilitar o acesso a informa¸c˜oes relativas a convites e ao estado dos diferentes torneios, foi adicionada uma barra informativa no canto superior direito. Na figura 4.34 ´e poss´ıvel observar a barra informativa com a parte correspondente aos convites recebidos. Aqui s˜ao apresentados os convites feitos aos clube do utilizador com Log In efetuado. No exemplo da figura apenas existe um convite recebido, onde ´e descrito qual o clube que efetuou o convite, qual o torneio e qual a equipa que foi convidada para participar no torneio.

Figura 4.34: Convites recebidos apresentados na barra informativa

O segundo icon da barra informativa disponibiliza informa¸c˜ao sobre o estado dos torneios que est˜ao a ser organizados pelo utilizador que tem Log in, nomeadamente a percentagem de clubes que j´a est˜ao confirmados para cada um dos torneios organizados por si(Figura 4.35).

Existe tamb´em uma zona destinada a alertas, que tˆem como objetivo notificar o utilizador quando alguma equipa por ele convidada aceitou o convite (Figura 4.36).

Figura 4.36: Alertas recebidos

Pr´emios personalizados

O organizador do torneio tem a possibilidade de adicionar pr´emios personalizados para equipas ou jogadores com base nas suas estat´ısticas, como por exemplo golos, cart˜oes ama- relos e cart˜oes vermelhos. O formato adotado para facilitar a inser¸c˜ao destes pr´emios ´e o apresentado na figura 4.37.

Figura 4.37: Upload de ficheiros

O organizador pode adicionar pr´emios aos seus torneios utilizando os tipos de pr´emios j´a existentes ou, caso pretenda, criando um tipo novo. A cria¸c˜ao dos tipos de pr´emios ´e feita com base em trˆes fatores, primeiro se o pr´emio se designa a um jogador ou a uma equipa, depois se pretende que seja a equipa/jogador com mais ou com menos golos/cart˜oes amarelos/cart˜oes vermelhos, sendo este o terceiro fator. Desta forma ´e poss´ıvel criar facilmente o tipo de pr´emio desejado, usando as diferentes combina¸c˜oes destes trˆes fatores.

Ordenac¸˜ao personalizada de grupos

Quando ´e realizada a adi¸c˜ao de uma categoria a um torneio, o organizador tem a possi- bilidade de escolher o crit´erio pelo qual devem ser ordenados os grupos, com base em quatro possibilidades (Figura 4.38).

Figura 4.38: Factores de desempate para ordena¸c˜ao dos grupos

Os fatores de desempate podem ser reordenados arrastando as caixas de acordo com as preferˆencias do organizador.

O resultado final resultou de uma adapta¸c˜ao do c´odigo presente na documenta¸c˜ao jqueryui [34].

Identificac¸˜ao dos campos com recurso ao Google Maps

A identifica¸c˜ao dos campos do clube ´e feita recorrendo `a utiliza¸c˜ao do Google Maps e de marcadores [35], sendo, depois, guardadas as coordenadas de cada campo na base de dados, juntamente com o nome que o identifica.

´

E utilizado geocoding [36] para obter a localiza¸c˜ao da sede do clube consoante a morada definida aquando da cria¸c˜ao do mesmo. Esta aparece no mapa com um ´ıcone diferente dos campos marcados.

Cap´ıtulo 5

Conclus˜ao

Nesta sec¸c˜ao ser˜ao comentados os resultados obtidos, assim como problemas que ocorreram durante o desenvolvimento deste projeto. Ir˜ao tamb´em ser discutidas as vantagens do sistema desenvolvido em rela¸c˜ao aos j´a existentes. Finalmente, ser´a referido algum trabalho futuro.

5.1

Conclus˜ao

Durante esta disserta¸c˜ao, foi desenvolvido um sistema capaz de organizar um torneio, percorrendo todas as suas fases desde a cria¸c˜ao at´e ao seu termo. A grande diferen¸ca entre o sistema desenvolvido e os j´a existentes ´e o facto de estar direcionado para clubes, possi- bilitando a partilha de informa¸c˜ao de equipas e jogadores entre todos os clubes registados na plataforma. Para al´em desta partilha de informa¸c˜ao, outra das vantagens que distingue a aplica¸c˜ao desenvolvida das existentes, ´e o facto de permitir aos organizadores convida- rem qualquer equipa registada utilizando um processo de 3 passos (Convite do organizador, aceita¸c˜ao da equipa convidada e confirma¸c˜ao por parte do organizador), que ´e suportado na totalidade pelo sistema. A possibilidade de edi¸c˜ao tanto dos convites enviados, como do re- gulamento, ´e, tamb´em, uma mais valia, permitindo ao organizador uma maior personaliza¸c˜ao do torneio que est´a a organizar.

Outra vantagem que n˜ao foi encontrada em nenhum dos sistemas testados e que est´a

presente no sistema desenvolvido, ´e que, para al´em dos jogos serem gerados, tamb´em s˜ao distribu´ıdos pelas horas e dias definidos pelo organizador, assim como pelos diferentes campos associados ao clube onde o torneio ´e sediado. Tanto a data dos jogos como o campo onde se realiza pode ser posteriormente modificado pelo organizador.

Em rela¸c˜ao aos problemas encontrados, a maior dificuldade foi em estabelecer a melhor forma de organizar os diferentes elementos e o modo como deveria ser feita a interface por forma a oferecer uma utiliza¸c˜ao intuitiva. O facto de nunca ter trabalhado com a framework tamb´em originou um trabalho extra inicial para perceber como devia ser utilizada. Por outro lado, o cruzamento das diferentes tecnologias foi bastante intuitivo havendo muita informa¸c˜ao dispon´ıvel para ser consultada. O facto de haver quatro fases de planeamento do modelo relacional deve-se fundamentalmente `a adapta¸c˜ao do modelo consoante as necessidades que foram surgindo durante o desenvolvimento do sistema.