Nested sandbox editors?

I received an interesting question in the mail today regarding Sandbox Editors and the advice I offered in a previous post:

I am using the Contact example with the SandBoxEditor and Editor for the basis of my app. When I have a listView which pops up a dialog should my dialog always use a separate repository instance to work with the detail record? If the detail record pops up a new dialog to gather some additional information should it also use a separate repository instance.

I guess what I am asking should I always protect a parent view from changes in a child until the user make the change permanent? Is this what you would do in a real application?

The essence of the question is in this one line: “should I always protect a parent view from changes in a child?”

First of all, I always avoid the word “always”.  But seriously …

The point of the separate repository is to isolate the editing context from the main application context. Within the sandbox I would tend to use the second, isolated repository everywhere … unless I thought the user experience required secondary isolation in which case I would “sub-sandbox.”  I’d be surprised if this is really what the user wants.

Let’s step back a bit. Early in my Sandbox Editor post I stressed that some folks prefer seeing the provisional changes propagated across the UI … as they happen. In my mind that is a perfectly reasonable experience. If the user expects it and the view design supports that expectation, all is well.

For example, if the grid and the detail form are side-by-side on the page, I personally would expect the grid to update as I typed in the detail form.

However, when the editor hovers on top of the grid (as it does in the Intersoft sample), I’m more inclined toward the sandbox editor. Even then it’s an option, not a rule. You have to feel it out with your users.

Notice that John Papa’s Book Club application has only one “DataService”. He does not sandbox. Changes in the overlay editor are reflected immediately in the grid. Is that good or bad?

Back to your question: should you “sub-sandbox”? Only you know what makes the best user experience for your application. The way you design the screens may influence your decision.

Myself, I would not sub-sandbox. To sub-sandbox would make it more complicated for me and, more importantly, seems likely to confuse my users. I would try to arrange the view so that they expected to see values propagate to the parent window. Maybe I wouldn’t have a parent/child window.

You won’t know what is “best” until you give your users a chance to try it. Maybe you can show them both designs (in a paper model) and see what they think.