mikaelsvensson
commented
3 years ago We have application logic in these front-end classes:
- AbstractGroupView, e.g.
check_event_is_ongoing - CompetitionSignup, e.g.
get_available_group_categoriesandcreate_group - Form, e.g.
update_answers - GroupCancelSignup, e.g. call controller instead of
updateon DAO - GroupCheckin, e.g. call controller instead of
updateon DAO - GroupEditor, e.g.
update_group - GroupPeopleEditor, e.g.
update_groupandget_current_group_members - GroupSignup, e.g.
create_personandsend_person_welcome_mail - PersonEditor, e.g.
update_person - PointsOverride, e.g.
update_pointsandget_optimistic_lock_value
The source code is somewhat decently structured but it could be better. A primary concern is that it's hard to create a REST API for the system when so much logic sits inside the "frontend" namespace.
Maybe we should take (more) inspiration from the MVC pattern? Our Model layer is pretty decent but the application logic is very tightly coupled to the presentation. Basically, we may want to split some files and classes into separate Controllers and Views.
Another part of this is to "modularize" the different types of competition tasks, like geo-fenced questions and ticketed manned checkpoints. Some such "competition tasks" may not be necessary for all competitions. Is there some shared functionality which can be extracted? Can such "competition tasks" be enabled or disabled on a per-competition basis to make it clearer what features will be available to admins and participants?