What is this?
Documentation and Tutorials for SoapBox Core.
Design Goals of SoapBox Core
I started writing SoapBox Snap (eventually to be released as GPL - for very good reasons that were discussed with a lawyer) and I had these requirements:
- It had to be extensible, so anybody could extend the functionality with Add-Ins without necessarily having to co-ordinate with me.
- It had to be WPF using the Model-View-ViewModel pattern.
- Everything I used had to be GPL compatible.
SoapBox Core is just my attempt to accomplish these goals. Now I understand that you can accomplish goals 1 and 2 with Composite WPF (aka PRISM) or the WPF Application Framework. Unfortunately they're licensed under the Ms-PL so I wouldn't have been able to use them in a GPL'd application. It turns out that MEF (which SoapBox Core uses for extensibility) is also licensed under the Ms-PL but it will eventually be included with .NET 4.0, and at that point it becomes a system library and the GPL doesn't care about it.
Once I started writing SoapBox Snap, I realized that a lot of the stuff I had written was probably applicable to writing other applications, so we decided to break off the generic stuff as a separate library called SoapBox Core and release it under the LGPL license so anyone can use it, even in proprietary applications. That is the (very short) story of SoapBox Core. It is what it is. I also hope that it will be an interesting reference application for people interested in how to follow the Model-View-ViewModel pattern in their applications.
SoapBox Core Philosophies
For better or for worse, these are the ideas that were floating around my head as I wrote SoapBox Core:
- Everything is an Add-In: Just like SharpDevelop, which influenced my thinking heavily, every significant feature should be implemented as an Add-In to SoapBox Core, and Add-Ins can extend other Add-Ins.
- Pragmatic Views: I am not a "Code-Behind Zealot". As far as I'm concerned, the Code-Behind is part of the View. As long as you only put View-related logic in there, it's still perfectly legitimate Model-View-ViewModel. I don't use them too much, but I also consider Value Converters to be part of the View as well.
- (Almost) Every Class is a ViewModel: In SoapBox Core, everything that implements IViewModel is a ViewModel, so I don't use the ViewModel suffix on my ViewModel classes. It just gets too verbose. In fact, almost every class in SoapBox Core that isn't imported from another library (like NLog, AvalonDock or Physics2D) is a ViewModel.
How Does SoapBox Core Work?
SoapBox Core uses MEF for both Extensibility and Inversion of Control. The startup executable is always SoapBox.Core.Host.exe. This takes care of searching the local directory for more "parts", and then composing them into a complete application, and executing the main window. If you're really interested in how the Host works, you can see the source code here.
Part of the startup tasks are to import any resource dictionaries that the various parts have exported, and add them all to the application resources merged dictionary. This is how SoapBox Core really takes WPF and MVVM to the next level. In your Add-In, define a ViewModel class and then implement the View as a DataTemplate. Put the DataTemplate in a ResourceDictionary and Export it. The Host will Import it into the Application Resources and WPF will take care of applying the View to the ViewModel whenever it sees the ViewModel in the visual tree.
If you want a more in-depth tutorial about how SoapBox Core works, check out the CodeProject article about Soapbox Core.
- Creating an add-in
- Extending the Host
- Creating Layout Items
- Creating a Pad (like a tool window) and showing it
- Creating a Document (the normal big window in the middle) and showing it
- Hiding Pads and Closing Documents
- Saving and Restoring the Layout
- Extending the Workbench
- Adding Extension Points
- Using the Messaging Service
- Using the File Dialog Service