Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate IDs in LocalLayoutPersistenceManager #54

Closed
pling-scottlogic opened this issue Sep 21, 2023 · 0 comments · Fixed by #60
Closed

Validate IDs in LocalLayoutPersistenceManager #54

pling-scottlogic opened this issue Sep 21, 2023 · 0 comments · Fixed by #60
Assignees

Comments

@pling-scottlogic
Copy link

pling-scottlogic commented Sep 21, 2023

Background

When attempting to operate on a layout that does not exist in local storage, the current behaviour of LocalLayoutPersistenceManager is to continue regardless (see Current Behaviour below). We want to change this so that an exception is thrown whenever we try to access a layout with an non-existant ID.

Current Behaviour

The current behaviour is as follows, when provided with an ID that does not correspond to any layout in local storage:

  • updateLayout will add a new layout (and metadata) with the provided ID
  • deleteLayout will leave local storage unaltered
  • loadLayout will log a warning and return an empty object

Work Required

  • Adapt the updateLayout, deleteLayout and loadLayout methods in LocalLayoutPersistenceManager, so that an exception is thrown if there is no layout or metadata in storage with the requested ID
  • Consider adding a common method to avoid duplication, e.g. validateId (use a consistent approach for all three methods)
  • Handle the new exceptions wherever the methods are being used*

* At time of writing, none of these methods are being used.

Notes

There is a warningLayout, which might be sensible to display when one of these exceptions is thrown.

Links

Initial discussion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants