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
6 comments:
Hey Ward - I noticed that the link you have in this article to http://drc.ideablade.com/xwiki/bin/view/Documentation/ClientUIDevForceIntegration is no longer valid. The same url is used in the pdf at http://www.ideablade.com/ClientUISample/2_AddSandboxEditorToContactsApp.pdf
I take it that that url was a 'home page' for the example project?
Thanks, Anonymous. Updated our links server to the new location of that DevForce Resource Center (DRC) page. The links should be working now. Appreciate the heads-up.
Hi,
Nice exemple.
When I try to do the same with a view located in another assembly (not an silverlight application, juste a DLL) I get an error (the instance of the view = null).
Maybe I got something wrong, is there a special way to name the view in the parameter of DialogBoxServiceProvider.GetInstanceAsync method ?
MyAssembly.Views.MyView isn't working. I tried a lot of possibilities.
@Anonymous - Sorry your having trouble. Even more sorry that I can't help you. My blog isn't a support forum. The answer to your question requires knowing the details of your experience. I suggest you contact Intersoft's forum our our IdeaBlade forum.
I can say that it should not matter whether the view is in the same or different assembly ALTHOUGH you cannot mix Silverlight and non-Silverlight assemblies in the same application (as you may be doing in one possible reading of your question).
I have been operating under the belief that the view should not be able to bind to or edit the model directly so this example bothers me.
Is this because it is a sample? If not, please share the why.
@Midnit - Nope. It's not because it's a sample. It's a concession to real-world practicality.
I am sympathetic with your perspective ... as I am with people who oppose property setters for business objects.
In my experience, however, the cost of such architectural goodness is never recovered. It is just too hard in today's .NET to write and maintain all of the mappings that are necessary to mediate between a plethora of "Item ViewModels" and their corresponding model objects.
That's why RIA products endow generated model objects with INPC and other databinding support features.
Go ahead and feel uncomfortable - you should - I know I do. But until the technology we rely upon makes Item ViewModels cost effective, we'll have to use them sparingly and live with direct binding to model objects.
Post a Comment