This project has moved. For the latest updates, please go here.

VM Access, Multiple Shells, and Change Notifications

Feb 2, 2011 at 12:14 AM

Hi Jeremy, first off, thanks for your contribution to the community. The Jounce framework is really slick and addresses many of the needs that I have from a UI standpoint. You have potentially saved me much time, so thanks for that.

Admittedely, I've only been looking into Jounce for a few hours, so forgive me if my questions are premature.

Sometimes having the view invoke members on the VM are a complete pain, and it's often (depending on which controls you use) easier just to handle an event in the code behind and call the VM directly. Does Jounce support this? I can't see how it does this due to the dynamic binding that occurs between the 2 at runtime.

I also have a need to create a portal that hosts different applications. So my question is, seeing as though only one view can be the "shell", can my sub programs also utilize the concept of the shell? Or maybe I'm going about this the wrong way? But basically, the main shell (or portal) will display links/buttons that will dynamically load the application into a main content area when clicked.

Lastly, within one of these programs (or maybe even across open programs), when the content of one control changes, I need any other controls currently loaded to be able to subscribe for change notifications. Again, I haven't had much time to really dig into Jounce, but it seems that the VisualStateAggregator might help me achieve this behavior?

Any direction in terms of past posts or samples would be greatly appreciated!

-Aaron

Coordinator
Feb 2, 2011 at 1:48 AM

Thanks for the kind words and I appreciate you posting this here!

Can you give some explicit examples of when "invoking members on the VM" are a pain? I have seldom found a scenario that I couldn't resolve with an InvokeMethodAction, a blend trigger than can be attached to any UI element and trigger from any type of event and simply call out to a method. There is a similar one for commands as well. It's just a drag-and-drop behavior in blend and not much more difficult to wire in Cider (the VS2010 editor). Do you have a specific scenario that this wouldn't address?

If you absolutely need to reference the view model in the run time, you can either cast the data context to the VM type when the event you're hooking into occurs, or satisfy imports in the view and use the view model router (you just import it into the view) to reference it that way.

The shell view is no different than the RootVisual of a Silverlight application, so it would be no different using Jounce or not for aggregate views. For the "concept" you're looking for I think perhaps you want a region that provides the "space" your component will register to. Then, it's as simple as in the main view model as raising the navigation event for the "shell" items that would go into the regions. Jounce will respond to that event and wire the items in place. There is also a navigation example in the quick starts that automatically wires navigation buttons based on the exports and then routes to the regions when they are clicked.

There are two types of "publish" style notifications. If the changes are solely UI-based then the Visual State Aggregator can be used to aggregate an event that triggers a state change across controls. If the event involves business logic, every view model has access to the event aggregator where you can publish and subscribe to global messages and communicate those to the views through data-binding.

I'll be working on a larger reference application using Jounce it's just been busy with Sterling and some other projects but I hope to have it out eventually.

Thanks,

Jeremy

Feb 2, 2011 at 2:12 PM

Ugh,immediately after posting, I realized how silly of a question it was to ask how to obtain reference to the VM.  If we haven't used someone else's MVVM framework, we've written our own, and I should have known that the VM is usually plugged into the DataContext of the view.  I think I got caught up in the dynamic binding and was thinking that you have some sort of mediator to marshal calls between the 2, or something crazy like that.

Thanks for the clarification on the aggregators and their responsibilities.  I will dig through the suggested quick starts as you suggest.

Aaron