...
Decision | Description |
|---|---|
Problem/Issue | There is no graph linked to a sensor. |
| Decision | There won't be an available graphs to add to a tab. |
| Alternatives | Give every sensor a normal table (for example), so there is always a graph available. |
| Arguments | Not every sensor has good enough data for a normal table. |
Delete Graph
The crewmember deletes a graph on the webpage. the front-end does a call to the back-end. This activates the getAllRaces method in the RaceResource. The resource is only responsible for returning the response so it gets delegated to GraphResource. The GraphService delegates this to the GraphDAO because getting the data from the database is not the responsibility of the controller. In the GraphDAO to delete the graph in the database. The benefit of this structure is that you can easily swap the classes which results in low cohesion and high coupling. This structure is based of the the layer pattern.
Tabs CRUD
During the development for the user tabs we got into an argument on how we were going to display the tabs a user can have. We came to the conclusion that it would be easier if we were to store the tabs in the database. This way the crewmembers don't have to recreate the tabs every time they would login. Also, this way every crewmember could design their dashboard the way they find easy to read.
...