We’re developing a full-stack WPF/Silverlight development series in concert with Intersoft Solutions using DevForce and Intersoft’s “ClientUI” technology. You can learn about the series and keep up with the latest developments on our website.
Today I’m announcing the second installment of the series which replaces the “synchronous” editor with a “sandboxed” editor.
With the initial “synchronous” editor, users changes entered in the child window editor are visible immediately in the main view, the view that lists the contacts, as we see here:
That immediacy is a good experience in some screen layouts … say when the detail editor is embedded in the same screen as the list view. But many people feel that a child window editor implies a temporary workspace. Unsaved changes should be confined to the editor; changes should propagate to the main view only after the user saves them.
For example, the unfinished editing session in which we changed “Andre” to “Bob” should look like this:
In other words, the editing experience should take place “in a sandbox”, hence the name “sandboxed editor”. In the second sample in the DevForce/ClientUI series, we make some small changes to turn the “synchronous” editor into a “sandbox” editor.
In a post to follow very soon, I’ll describe the issues in detail and the code to get it done.I’ll be excerpting from the walkthrough document that accompanies the second code sample.
While that walkthrough is specific to the ClientUI sample, all of the principles and many of the techniques are applicable no matter how you build your DevForce application.
Go ahead … jump ahead of me and read that document. Or you can wait for me to re-cast it here in my blog in a few days. Either way, you can’t lose.
Happy holidays!
Update: Checkout the related post in which I answer an email about nested sandbox editors
