The Library App That Nobody Could Log Into
A Year 12 team is building a school library booking app for their SAC. Their design uses three layers: a presentation layer (the web forms), a business layer (booking rules such as 'a student may hold at most three active bookings'), and a data layer (database access). During testing, a student can create a fourth booking by submitting the form twice quickly, even though the interface normally blocks it after three. A teammate proposes fixing this by disabling the submit button with JavaScript as soon as it is clicked. The teacher notes that the rule already exists in the business layer, but the business layer calls the data layer once per form submission without re-checking the count inside the same transaction. The team has four days before the SAC demonstration and a working, simpler version due tomorrow.
1. Explain why the JavaScript button fix does not properly resolve the defect, and state where the authoritative check belongs.
Read the worked answer
Why the button fix is insufficient: Disabling the button is a presentation-layer control. It can be bypassed by refreshing, using browser developer tools, a slow network, or a second tab, so it does not enforce the booking rule. The symptom (double submission) is a race between two requests, not a UI problem.
Where the check belongs: The business layer must own the rule. The count of active bookings should be checked and the new booking inserted atomically - inside one transaction with appropriate locking - so two concurrent requests cannot both see 'two bookings' and both insert. The data layer must support this (for example, a transaction plus a constraint).
Judgement: JavaScript may remain as a convenience (fast feedback), but it is defence in depth, not the authority. The team should fix the business/data layer first.
2. The team has four days and a working simpler version due tomorrow. Recommend an action plan and justify the trade-offs.
Read the worked answer
Recommendation: Ship the simpler working version tomorrow (it demonstrates the layered design and the core booking flow). Then, over the remaining days, prioritise the transactional fix in the business layer, because it is a correctness/security issue affecting the SAC's stated rule.
Trade-offs:
- Keeping the JavaScript button disable is cheap and improves the demo experience, but it must not be presented as the fix.
- A full redesign (e.g. optimistic concurrency with version numbers) may be overkill for four days; a transaction-scoped re-check is a smaller, safer change.
- Testing the race condition is hard manually; the team should add a script or repeat automated submissions to verify the fix.
Justification: Correctness of a stated business rule outranks polish. Deferring the fix risks the SAC failing a stated requirement, while the simpler version preserves a demonstrable baseline.