Silverlight + MVVM = More questions

[Jeremiah Morrill]

I'm still trying to grok, as they say, MVVM in Silverlight.  So if any of this sounds ignorant, don't be shy about letting me know.

So essentially I have a ViewModel such as this:

    public class MainLayoutViewModel : ViewModelBase
    {
        private LoginViewModel m_loginController = new LoginViewModel();
        private TestViewModel m_testController = new TestViewModel();
        private ViewModelBase m_currentViewModel;

        public MainLayoutViewModel()
        {
            CurrentViewModel = m_loginController;
        }
      
        public ViewModelBase CurrentViewModel
        {
            get { return m_currentViewModel; }
            set
            {
                m_currentViewModel = value;
                InvokePropertyChanged("CurrentViewModel");
            }
        }
    }

Now when my LoginViewModell "authenticates", I suppose I want to change the "CurrentViewModel" property to a new view model.  In my View, I would like to change the DataTemplate "View" to the matching ViewModel, but it seems something like this is not supported in SL.  I found some great support for this in the SL Extensions (ResourceSelector), but I was wondering how everyone else does this, or if there is a better way or if I'm just doin' it wrong?  My View with the SL extension looks like this:

<UserControl x:Class="SKMEventUI.MainLayoutView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Views="clr-namespace:MyNamespace.Views"
    xmlns:Data="clr-namespace:SLExtensions.Data;assembly=SLExtensions"
    xmlns:Controls="clr-namespace:SLExtensions.Controls;assembly=SLExtensions.Controls">
    <UserControl.Resources>
        <Data:ResourceSelector x:Key="controlTemplateSelector">
            <ResourceDictionary>
                <DataTemplate x:Key="LoginViewModel">
                    <Border BorderBrush="Black" BorderThickness="1,1,1,1">
                        <Views:LoginView/>
                    </Border>
                </DataTemplate>
                <DataTemplate x:Key="TestViewModel">
                    <Views:TestView />
                </DataTemplate>
            </ResourceDictionary>
        </Data:ResourceSelector>
        <DataTemplate x:Key="controlItemTemplate">
            <ContentControl Content="{Binding}"
                            ContentTemplate="{Binding Converter={StaticResource controlTemplateSelector}}" />
        </DataTemplate>
    </UserControl.Resources>
    <StackPanel x:Name="LayoutRoot" Background="White">
                <ContentControl  Content="{Binding CurrentViewModel}"
                         ContentTemplate="{StaticResource controlItemTemplate}" />
    </StackPanel>
</UserControl>

[Corrado Cavalli]

Hi Jeremiah,

Are you trying to implement a sort of Login page then, after authentication, do you want to ‘move’ to main page?

 

Corrado

[Jeremiah Morrill]

Yeah, specifically here, that's exactly what I'm trying to accomplish.  Generally, I want be able to "replace one control with another", and of course stick close to being MVVM.  The ContentControl would eventually be replaced with something that would maybe do a transition when the content changed.

I know some things need a little home-brew TLC in SL (ie Commanding), but I am left wondering if I'm applying the pattern incorrectly and/or not leveraging the SL framework.  So far, to me, making controls on a lower level makes a lot of sense, but gluing them together at a higher level is where my understanding of how to implement MVVM in SL falls apart.

-Jer

[Corrado Cavalli]

Think you’re in wrong direction, you have to change rootvisual content, my application uses a navigation system based on this blog and it works great!

In my case, I changed the logic a bit because, after login only the internal area has to change based on navigation but approach is exactly the same

 

http://www.flawlesscode.com/post/2008/03/Silverlight-2-Navigating-Between-Xaml-Pages.aspx

 

Corrado

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Jeremiah Morrill

Sent: sabato 29 novembre 2008 10:57
To: wpf-di...@googlegroups.com

Subject: [WPF Disciples] Re: Silverlight + MVVM = More questions

 

Yeah, specifically here, that's exactly what I'm trying to accomplish.  Generally, I want be able to "replace one control with another", and of course stick close to being MVVM.  The ContentControl would eventually be replaced with something that would maybe do a transition when the content changed.

I know some things need a little home-brew TLC in SL (ie Commanding), but I am left wondering if I'm applying the pattern incorrectly and/or not leveraging the SL framework.  So far, to me, making controls on a lower level makes a lot of sense, but gluing them together at a higher level is where my understanding of how to implement MVVM in SL falls apart.

-Jer

On Fri, Nov 28, 2008 at 9:25 PM, Corrado Cavalli <corrado...@gmail.com> wrote:

[Laurent Bugnion, GalaSoft [MVP]]

I am with Corrado on that one. The idea in Silverlight is a "Page" based
navigation. I put "Page" in quotes because it's actually a UserControl, but
still, the idea is heavily inspired from WPF's navigation service. There are
even frameworks implementing this (see
http://blogs.telerik.com/BoryanaMiloshevska/Posts/08-10-03/Page_Navigation_f
or_Silverlight_2_RC0.aspx for instance).

Another advantage of having the App taking care of the navigation is that it
is able to read query string parameters or even the parameters entered in
the "object" tag, and so a bookmarked navigation is also easy to implement.

Cheers,
Laurent

http://www.flawlesscode.com/post/2008/03/Silverlight-2-Navigating-Betwee
n-Xaml-Pages.aspx

Corrado

-Jer

Hi Jeremiah,

Corrado

great support for this in the SL Extensions <http://slextensions.net>

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.11/1818 - Release Date: 11/28/2008
7:31 PM

[Jeremiah Morrill]

Thanks guys.  This surely answers my question on moving from the LoginView to AnotherView.  But does this navigation method work well on all levels of the UI?

For an example, say I had a LionView, TigerView and BearView (all with their complimentary ViewModels).  Now visualize a stereotypical LOB "Page", with a handful of controls (ie product lists, datagrids).  Say one of these controls was a 200x200 containing 3 buttons.  Let's call it the ZooView.  When any of these 3 buttons are clicked, it would load up a "LionView", "TigerView" and so on, within the ZooView.  Of course in this situation I wouldn't want to navigate to a whole new "RootVisual", just "navigate" one control to another. 

This is all really trivial, but I feel like I "break" the MVVM pattern and it mutates into some crazy ModelViewPresenter-ish-MVVM monstrosity.  There's no DataType property on the DataTemplate in SL, so the ResourceSelector from the SL extensions lib seems to fill the gap in making the SL View more intelligent as to what DataTemplate (or View) to use with a given ViewModel.

Hope this email wasn't a diaremail =P

-Jer

[Josh Smith]

Nice usage of "diaremail"...though I don't think your reply qualifies as one. :)

There are two pieces to this puzzle, imo.  One piece decides what to show, the other piece decides how to show it.  I think the first piece is properly handled in the ViewModel, as you suggested.  The second piece should be handled as a platform-level service, like typed DataTemplates in WPF.  However, as you pointed out, since SL doesn't have this, I think using an extension class is ideal.

What you're describing makes sense to me.  What exactly is the problem that you are concerned about?

Josh

[Jeremiah Morrill]

I was looking for validation of my approach...I'd hate to have to unlearn anything ;).  All the MVVM SL examples I've looked at, have a single "Page" with a VM and maybe an ItemsControl/Panel or ListBox, that would be databound to a collection of VMs.  I have not seen an MVVM example showing how to dynamically change specific controls in the View *from* the ViewModel.  I was starting to clutter my View's codebehind to handle a lot of that, so thats why I said it started being like the MVP/MVVM hybrid...and it surely didn't look as clean as a WPF MVVM.

My main concern, was that life seemed good with a 3rd party solution...which makes me sometimes think I'm not leveraging the framework I'm using correctly.  And also wondering how anyone else does stuff like this within their own applications.

Thanks all...I feel like I'm well on my way to MVVM nirvana in SL.

-Jer

[Mike Brown]

I don't know if this trick will work in Silverlight but one technique I used in WPF was to have a Control as a place holder and used a trigger to change the template (and thus contents) of the control based on what object I wanted to display. I used it similar to your "Zoo" scenario, where there were multiple classes of objects that I wanted to perform the same operation upon. I never wrote about the technique because I wasn't sure if it qualified as very useful or not. But since it seems someone else can use it, I can give a quick post about it.

[Jeremiah Morrill]

I think triggers are pretty limited in SL 2.0.  AFAIK, there are only event triggers, but you can't define your own routed events.  Not sure that can be implemented without some home-brew infrastructure.  This SL Extension library has the makings of a routed event framework, but I have yet to try it on.

-Jer

[Mike Brown]

So there are no DataTriggers in Silverlight? WTF! Who dropped the ball on that one?

[Paul Stovell]

The same guy who also removed:

• Triggers
• Element binding
• Relative source binding
• TypeDecriptors
• Dependency property inheritance
• Template binding to attached DP's
• Ability to subscribe to Changed events on DP's
  

But they gave us a DataGrid, so it's OK :)

--
Paul Stovell
http://www.paulstovell.net

[Mike Brown]

Oh...well that makes up for everything :|

[Jeremiah Morrill]

Whomever, "that guy" is...He's a brave one.  It takes a lot of guts to remove all those and laugh at the thought of rabid developers hunting him/her down.  ;)

 

I still feel there's a lot of bang for the buck in SL.  Even with my initial frustrations, I was able to talk myself off the ledge by chanting "At least its not ActionScript...At least its not ActionScript...".  =P

 

-Jer

[Corrado Cavalli]

Add MarkupExtension class J

 

-Corrado

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Paul Stovell
Sent: domenica 30 novembre 2008 04:59
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: Silverlight + MVVM = More questions

 

The same guy who also removed:

• Triggers
• Element binding
• Relative source binding
• TypeDecriptors
• Dependency property inheritance
• Template binding to attached DP's
• Ability to subscribe to Changed events on DP's

But they gave us a DataGrid, so it's OK :)

[Marlon Grech]

they say Silverlight is the little brother of WPF.... apparently from a different father....

--
Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Laurent Bugnion, GalaSoft [MVP]]

I am sworn to secrecy ;) but there is a lot in store for Silverlight 3. Patience, grasshoppers, patience…

 

For the records, the story of triggers in SL is as follows:

 

·         Triggers are apparently really hard to implement, and the team had to give up.

·         They implemented VSM instead

·         Then they saw that VSM was actually pretty cool

·         So now VSM is going to flow into WPF.

·         Triggers *should* go into SL some day too, but I wouldn’t hold my breath

 

The only event trigger that is “supported” is the Loaded event, which is nothing more than a remain from the past (SL1) and so it is recommended not to use it. I usually prefer to trigger the animations in code.

 

At least, it’s not ActionScript ;)

 

Laurent

Version: 8.0.176 / Virus Database: 270.9.11/1820 - Release Date: 11/29/2008 6:52 PM

[Mike Brown]

Okay...I guess I have to bite the bullet...

[John Gossman]

WPF was designed and implemented as a core, no-compromise Windows component.  In order to get a small, portable, factored implementation of WPF that would work the same on Windows and non-Windows including Mobile devices that don't even run the CLR, we reimplemented much of the framework.  We will be adding other WPF features as time goes on.  I wrote about some of the harder choices here:

http://blogs.msdn.com/johngossman/archive/2008/05/01/silverlight-the-art-of-subsetting.aspx

[Mike Brown]

To be honest, I understand fully the sacrifices and decisions that needed to be made with Silverlight. When I said bite the bullet, I meant I had put off learning VSM for a while. I'm going to stop procrastinating and spend a good weekend with SL2U. To be fully honest, I'd prefer to see 3D before triggers...if the VSM supports a workaround then I'm all for it!