0

My application is used by parents and their children.

I should like to allow a parent to edit details about their children from their account page. I envisage a single form where the upper section contains fields about the parent and the lower section contains fields about a child. If a parent has more than one child, the lower section will be tabbed; one tab per child.

I'd like to achieve a RESTful design if possible. The options I've considered so far are:

Option 1 - Expose the parent and all children (list of nested child forms) via the parent's resource route and then use JavaScript to change the UI into a tab-based layout.

Option 2 - Expose the parent and one child (nested form) via the parent's resource route. Expose the same page but for a specific child via nested routes.

So:

'GET /parent/1' will render the account page of the parent with a nested sub-form for the 'first' (default) child. It will also contain two or more clickable links (styled as tabs) which link to nested routes; one for each child (e.g. 'GET /account/1/child/1' and 'GET /account/1/child/2').

Each nested route will be serviced by a 'kids' controller which will in effect render the exact same parent's account page as would be rendered by the parent route/controller but with the appropriately populated sub-form for the child resource addressed by the route.

Option 2 would seem to be a feasible approach but I would welcome feedback, and any other ideas.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Lee
  • 1

1 Answers1

0

In either approach, you might have difficulty navigating among the children if you have not saved the parent yet. If you navigate from child 1 to child 2, how can you store the information about child 1, now that you will be replacing the child 1 tab by rendering the form for child 2. Maybe Option 1 handles this, by hiding the data, but Option 2 definitely has this issue.

I recommend having the user first save the parent data, then edit the data for children, but not try to edit the parent data and children data at the same time.

This is a good use of nested routes. Usually there is a cost to nested routes that you have to keep sending the reference to the outer nested objects. In this case, you do want (or don't mind) a reference to the parent, since that is very important to your workflow.

However, just because nested routes will work well, doesn't mean that the Javascript option might not be better. After, you don't have to reload the page in the middle of editing children data. At worst, you have to load a partial to add a new form if they have one more child than you accounted for.

Marlin Pierce
  • 9,931
  • 4
  • 30
  • 52
  • Thanks, Martin. To clarify, your non-JavaScript recommendation is to have two separate forms on the parent's account page; one for the parent and one for the child. The child form will make use of the nested route and 'children' controller. Do I understand you correctly? Where should the user be re-directed after a successful save of the child form? What should happen if the save is unsuccessful - I assume the 'children' controller will have to render an identical account page to that initially rendered by the 'parent' controller but with errors. – Lee May 08 '12 at 13:30
  • Yeah, something like that, you understand. This is the way I might do it, you could get it to work with one page. I just think it simplifies some things. As for redirecting after a successful child info save, it depends. You might have the tab to another child submit, update, and redirect to the form for the next child. So you might end up checking the submit button for where to go next. Also, use partials to handle redundant rendering, like for the parent show info, and maybe errors. – Marlin Pierce May 08 '12 at 14:11