Aktualne działanie serwera InFUN

Schemat budowy komponentu

ExampleGame
 |__ css
 |__ img
 |__ lib
 |__ js
 |
 |__ config.json
 |__ index.html

{
	"name": "task_1",
	"config": [
		{
			"name": "sth",
			"value": "default_value",
			"required": true
		},
		{
			"name": "sth_2",
			"value": "default_value_2",
			"required": false
		}
	]
}

Komunikacja komponent-serwer

Komunikacja odbywa się poprzez Rest API.

Przed rozpoczęciem gry

GET /{game}/config

Response: 200 OK
Body:
{
    "group": "$string",
    "nick": "$string",
    "age": "$integer",
    "config": [
     ...
    ]
}

Po zakończeniu gry

POST /{game}/end

Body:
{
    "score": "$integer",
    "group": "$string",
    "nick": "$string",
    "age": "$integer"
}

Response 200 OK

Strony udostępniane przez serwer

• /createGame
  • tworzenie rozgrywki grupowej
  • ustalenie możliwych gier komponentowych w rozgrywce
• /manage
  • panel administracyjny rozgrywki
  • przedstawia wykresy aktualnego stanu rozgrywki (wyniki graczy)
  • gdy uderzamy do niego bezpośrednio wyświetlany jest błąd "Nie wybrano żadnej rozgrywki"
  • gdy przekierowany z /createGame tworzy w kontrolerze nową rozgrywkę
• /joinGame
  • strona umożliwiająca użytkownikowi dołączenie do rozgrywki o danym groupId
  • po zatwierdzeniu formularza użytkownik dodawany do gry (użytkownik identyfikowany po ciasteczku JSESSIONID)
  • gdy użytkownik już jest dołączony do jakiejś rozgrywki, zwracany błąd "Użytkownik z ciasteczkiem ${JSESSIONID} już istnieje"
• /newTask
  • redirect do /task/new
• /task/new
  • przydziela grę dla gracza
  • gracz identyfikowany po sesji z ciasteczka
  • gdy gracz nie był dołączony wcześniej do żadnej rozgrywki zwraca błąd "Nie ma użytkownika z ciasteczkiem = ${JSESSIONID}"
  • po zakończeniu gry przez użytkownika przekierowany do /taskResult
  • gdy gracz rozegrał już wszystkie gry w danej rozgrywce przekierowywany do /end
• /taskResult
  • wyświetla wyniki ostatniej gry użytkownika
  • pobiera dane poprzez zapytanie do Rest API serwera: GET /last/results, identyfikacja użytkownika na podstawie ciasteczka JSESSIONID
• /end
  • wyświetla wynik użytkownika w rozgrywce

Rest API wykorzystywane przez strony View serwera:

• GET /last/results
  • zwraca wynik ostatniej gry użytkownika autentykowanego na podstawie ciasteczka JSESSIONID
• GET /{groupId}/results
  • zwraca aktualne wyniki graczy w rozgrywce o danym groupId
  • gdy zapytanie z ciasteczkiem JSESSIONID innym niż wykorzystane przy tworzeniu rozgrywki, zwracany błąd
• GET /{groupId}/remove
  • usuwa rozgrywkę z danym groupId
  • gdy zapytanie z ciasteczkiem JSESSIONID innym niż wykorzystane przy tworzeniu rozgrywki, zwracany błąd

Braki w funkcjonalności serwera

1. Niezrozumiałe błędy pokazywane są użytkownikowi Nie ma użytkownika z ciasteczkiem = E10BE28E8F084118C5B7C02E7BF3A234
2. Brak powrotu do poprzednio stworzonej gry.
3. Brak walidacji na frontendzie, np. gdy nie wypełni się żadnej gry.

Braki w kodzie serwera

1. Nieużywane klasy.
2. Nieużywane parametry w metodach klas.
3. Słaba separacja logiki: np. Game.java jednocześnie przechowuje dane gry (getter + setter do wszystkich pól) i zawiera logikę.
4. Pomieszanie w klasie kontrolera InfunController.class endpointów z REST Api z endpointami wykorzystywanymi przez MVC.
5. Logika w kontrolerze powinna być przeniesiona do klasy serwisowej.
6. Dużo niepotrzebnego zakomentowanego kodu.
7. Błędy są w całości wypisywane do logu.
8. Bezpośrednie logowanie do konsoli przez System.out.println zamiast z wykorzystaniem logera