Appearance
Lesson 5 assignment — Finish Employee Task Manager
Continue the application you planned and started in the guided lesson. Focus on complete behavior, clear feedback and evidence that each requirement works.
1. Start here
Before starting: read Lesson 5's project brief. Data: local tasks.json. Persistence: browser memory only.
Continue the same Lesson 5 project folder. Review which features already work, then use this brief to complete and verify the remaining requirements.
If you have not begun the project, follow the guide's project setup, create tasks.json from its example, and work through the planning and reading-data steps. Return to this brief when you are ready to continue. Record any remaining work in your notes.
For a fresh project copy, run npm ci, then npm start. Stop any server still running from another project.
2. Your brief
Complete a single-screen Employee Task Manager for Anna Meyer. Use the employee and two task records from the guide's tasks.json example. Your application must let a user:
- Read the employee name, department and status.
- Read task titles and their Open/Done statuses.
- Enter a task title and add an Open task after validation.
- Toggle one task between Open and Done.
- Delete the selected task without changing other records.
- Understand when data is loading, when loading fails and when the task list is empty.
Keep /employee, /tasks and /draftTask/title as the model structure. Titles may repeat; task IDs must be distinct among the current records. Use the numeric-ID pattern from Lesson 4. Reusing a deleted ID is acceptable for this local exercise.
Use semantic control IDs, associated labels and row actions inside the bound item template. If you use a List or Table template, keep templateShareable: false. A List with CustomListItem or the responsive table pattern from Lesson 4 is suitable.
The app must keep Add unavailable until seed data has loaded successfully. It must reject empty/whitespace-only titles, explain what to enter and clear the draft after successful creation. Reloading intentionally restores the seed data.
3. Work through it
A. Decide the next missing behavior
In assignment-day-05.md, mark each of the six requirements Working, Partial or Missing. Work in this order: loading and display → creation → status changes → deletion → error recovery and usability. Keep already working features intact.
A complete required flow is more valuable than extra decoration. This project uses the controls and model operations from Lessons 1–4; additional routes, fragments, OData or backend code are not required.
B. Complete row actions
Read the task context from oEvent.getSource().getBindingContext(). For a status change, update the selected context's status through the model. For deletion, read that task's ID, filter the collection and write the remaining array through setProperty.
Re-read the context on every action. Verify actions after a deletion, when the remaining records have moved to new array positions.
C. Make failures understandable
Retain a safe initial model shape, a loading state and visible failure feedback. Keep Add disabled after a failed load. For invalid input, use a specific field message and focus the task-title Input. Restore normal field state on a successful retry.
The empty list needs useful text, such as No tasks yet. Add your first task. Explain the reload behavior in the project README so someone trying your app understands its persistence limits.
D. Prepare a reproducible project
Update the project's README.md with its purpose, prerequisites, run commands, implemented operations and the fact that changes reset on reload. Keep the existing setup information accurate. Run npm run build and record the result. A successful build checks packaging; you must still exercise the browser interactions below.
Application files to change: the Main View and Main Controller, plus the project README and assignment-day-05.md. Preserve the supplied seed data structure. Update app-title text only if needed for clarity, as described in the guided lesson.
4. Verify your result
Reload before D05-01 and run the normal-operation tests in order. Use reload to reset the seed data whenever a failure test or a fresh scenario requires it.
| Test ID | Action | Expected result |
|---|---|---|
| D05-01 | Load the app | Anna Meyer, Sales, Active; Prepare weekly report is Open and Contact customer is Done. |
| D05-02 | Add Book a meeting room | One Open task appears with trimmed title; the input clears. |
| D05-03 | Submit empty input, then spaces only | No task added; useful field error and focus; other tasks unchanged. |
| D05-04 | Correct the title and add again | Error clears and exactly one task is added. |
| D05-05 | Toggle Book a meeting room twice | Only that task changes Open → Done → Open. |
| D05-06 | Add two tasks called Follow up; mark one Done; delete the Open copy | Only the selected copy disappears; the Done copy and unrelated tasks remain. |
| D05-07 | Delete the first visible task, then toggle another | The intended remaining task changes despite its new array position. |
| D05-08 | Delete all tasks, then create a new one | Useful empty-state text; creation still works. |
| D05-09 | Reload after those changes | The original employee and two seed tasks return. |
| D05-10 | Throttle the network and reload | Loading is indicated; Add is unavailable until loading succeeds. Turn throttling off afterward. |
| D05-11 | Test a missing seed file and, separately, invalid JSON; restore each | Failure feedback appears; Add stays disabled; restoration and reload recover the app. |
| D05-12 | Use keyboard controls and test near 390 px wide | Fields are labeled; task text and every action remain reachable and usable. |
| D05-13 | Restore all faults, inspect Console and run npm run build | No unresolved application errors from your code; build completes successfully. |
| D05-14 | Review the README, final commit and git status | Run instructions are complete; source and notes committed; working tree clean. |
For D05-10, use DevTools → Network throttling; disable the browser cache while DevTools is open if a cached response hides the delay. Restore the normal settings afterward. For D05-11, follow Lesson 4's temporary-file failure procedure, using tasks.json and tasks-backup.json instead. Keep a valid backup and restore the supplied seed before submission.
5. If you get stuck
Hint 1 — the list is empty even though the request succeeds
Check that the default model is attached to the correct View and that the list binds to /tasks. Inside its template, use title and status relative to the task context. The form uses the separate absolute path /draftTask/title.
Hint 2 — two same-title tasks are deleted together
Delete by the selected record's unique ID, not its title. Also verify that creation produces an unused ID. Two records are allowed to have the same display text.
Hint 3 — a row button has no task context
Keep that button inside the bound row template. A button outside the list does not inherit a particular task's context. Check that bindings and getBindingContext() refer to the same model.
Hint 4 — I need a reference to recover
Revisit Lesson 4's controller and adapt one operation at a time. After an independent attempt, compare the completed Lesson 5 reference in a separate folder. Record what you adapted and trace the handler yourself. Keep your own test results and explanations.
6. Submit and reflect
Submit day-05-assignment.zip with the runnable source, project README and assignment-day-05.md. Include all fourteen test results and any remaining issues. Follow the shared packaging instructions and include the final commit summary in the submission message.
Prepare a short demonstration: reload → add a task → toggle it → delete a different task → reload again. Explain the data flow as you go. If you are studying independently, write the explanation in your notes instead of presenting it live.
Answer:
- Trace one task from the draft Input to the model collection and its displayed row.
- How does a row action identify the intended task, including when titles repeat?
- What would need to change to store tasks permanently, and why is changing the JSON URL alone insufficient?
7. Optional challenge
Add a Reopen action inside each task row. It should set only that task's status to Open. Test it on Done and Open tasks and after deleting a different task. Keep the existing Toggle and Delete behaviors and all required checks passing.
8. Continue and use references
Keep Project 1 and your earlier checkpoints. Lesson 6 will deepen binding contexts and list/detail patterns; you do not need to add those features to this submission.
- Lesson 5: project requirements and planning
- SAPUI5 JSONModel API
- SAPUI5 binding-context example
- SAPUI5 CustomListItem API
- SAPUI5 ID handling
Use SAPUI5 1.148.12 for the course examples. References checked on 15 November 2026.