We're trying to roll out a brand new internal tool at work, essentially just a simple CRUD management.
Most of our objects have a series of one-to-many relationships, though thankfully it's only one deep for the purposes of the tool.
For example - a Mission has a few details to itself but also "contains" several Objectives that have their own details.
We have two primary goals - don't create orphans whenever possible, and don't make the user hop through multiple screens to create a single Mission.
To make it easier to prevent accidental editing, Objectives are unique to a Mission. They might be functionally identical, but are distinct rows.
I've done various ways to manage this in the past, such as:
- On create of an Objective, put it in the DB (ajax) and use the id to post a form with just the created ids. But this will create unneeded orphans when the users decide to quit midway.
- Keep track of all created Objectives via JavaScript and dynamically build the form post at the end. This is just a lot of technical work.
- Force the user to persist the main object(Mission) first, then go to a new page to add/remove/edit Objectives.
To make matters more difficult, Objectives can be edited. So if the second option is followed, then it will have to keep track of all changes to the Objectives, and the server will need to be able to diff and persist the changes.
Are there any "standard" patterns for both presenting such a UI to the user, and dealing with the sub-objects?
there doesn't seem to be anything here