As the first step towards the new course book, the main course book page should be created. As the existing mock-up states, this should contain a table of lesson documentations (with a button at the end of the page that triggers new documentations to be loaded and the possibility to implement infinite scrolling at some point in the future; see #270 (closed)), created when some field in a documentation is edited. The basic filter functionality seen in the mock-up should be added. From the start on, the page should be mobile and desktop friendly. Management features for personal notes/absences/lesson documentations, the additional absence overview page and export functionality are to be added later on.
frontend queries documentations for a group and a time range
backend generates a list of existing documentations and dummy-docs for lesson events without a documentation (empty documentations don't have to be persisted in the database)
frontend receives a list of documentations to display
frontend is unaware if the documentations are persisted or not
this way the frontend only has to deal with one type of documentation
when editing data related to a documentation, the backend decides whether it is actually an update or also a create operation
the backend creates the documentation based on information coded into the dummy id (if there is one with this lessonevent, the existing one is updated)
the dummy id is a string of the following format: DUMMY:{LessonEventID}
a documentation has a field firstOfDay which may contain true if this is the first documentation of this day in this collection (→ can vary depending on filtering, is needed for the display of subheadings)
Sounds very reasonable to me. I also advocate for putting the main part of business logic into the models, so please adhere to this. How is your plan to implement this? Who does what in the next time?