locked
Can I present a Data Model to Blend 3 to allow Designers to bind to our data at run-time? RRS feed

  • Question

  • Greets,

    We have a clearly defined data model to which we want expression developers to hook up at design time.  Is there a Class Library DLL that we can provide to designers in a way that they can import it; then, after doing so, be able to pick and choose the properties from that data model (or any sub-properties from complex classes) so that they can be presented to the user?

    The idea is to expose the data that will actually be used by the application, but allow the designer to pick and choose which data they which to display for the purposes of being viewed or modified.

    The data that is being bound would be bound at run-time with the original application so that the output from Expression Blend would be copacetic with the actual Silverlight application itself.

    Regards,

    Joe

    Sunday, August 9, 2009 4:21 PM

Answers

  • Hi Harry,

    Actually, I'm replying to your post because I have finally after several trials and tribulations come to a conclusion.  We are using the MVVM (Model-View-ViewModel) pattern and what I have done was create a ViewModel class which exposes properties (while performing some business logic under the hood) that are meant to be bound to controls in the XAML.

    A shell (empty) Silverlight class library is created using the ViewModel interface (nothing is done under the hood) and the class library is added as a reference to the Expression Blend project.  Our Expression Blend users can then set on the main page a DataContext of the ViewModel as a CLR data binding.  Then, when actually creating the bindings to all the controls on the page, they choose "Explicit DataContext" which shows all of the properties that they can choose from to tie to that particular control.

    The end result is XAML which: a) adds a resource to the page to create an instance of the ViewModel (which the developers actually remove from the XAML); and b) all the remaining bindings to those properties "just work" when the XAML is processed in the development project with a ViewModel that implements the same interface (properties, etc.) but exhibits the correct business logic, communicates with WCF services, etc.  A very good separation of the UI from the actual code behind.

    The XAML is just text --as long as Blend creates the same 'Binding' paths on a 'dummy' class library CLR object that match the same as the production class library objects (and we remove the StaticResource that Blend added to the resources), then it works just swimmingly.

    I know this is almost three months later since your post (and four since mine), but I think that after delving in further, putting things into practice (i.e. suffering trials and tribulations) I can finally see how things are evolving.  One question I have left yet is behaviors....  however, that will be up to a new post.

    Cheers,

    Joe
    • Marked as answer by JFalcon Friday, December 18, 2009 4:53 AM
    Friday, December 18, 2009 4:51 AM

All replies

  • Howdy,

    If your CLR object has inherited from ObservableCollection<T>, your designers should be able to add it at design time. You just need to set a DP or Auto property from the constructor

    HTH

    Cheers

    Expression MVP

    my blog : http://x-coders.com/blogs/sneaky/default.aspx

    Sunday, August 9, 2009 5:49 PM
    Moderator
  • Greets Brennon,

    In this case, the object doesn't inherit from an ObservableCollection; however, it can have members that do so.  For example, say I have this type of class:

    public class Person
    {
       public string Name { get; set; }
       public int Age { get; set; }
    }

    Is there any way if I put this class into a class library DLL that I could expose it to Expression Blend (adding it as a reference) so that 'Name' and 'Age' could be dragged and dropped or somehow 'bound' to fields in XAML that is being modified by the user?

    In other words, I basically want to give the user a 'menu' of items that they can use when data binding and when running the application, it will bind to the correct data structure after I set the DataContext where appropriate.  I would like for the user to be able to pick and choose (from design time) all of the members that will be bound at run-time; however, they need the ability to see all the members of the data structure when designing.

    If this is possible, it would make Expression Blend the ultimate tool for seperating the UI from the code itself.  Is this possible?

    Regards,

    Joe

    Sunday, August 9, 2009 9:02 PM
  • JFalcon,
    What you described looks like the feature in Blend 3: sample data creationg and binding.
    Type "Sample data" at Blend Help document index, select "creating" or "modifying" sub-title. That will give you detail steps on how to use that feature to design a data model in design time and switch to live data in run time.

    Thanks.
    Thanks, Harry Huang [MSFT]
    Thursday, September 10, 2009 7:54 PM
  • Hi Harry,

    Actually, I'm replying to your post because I have finally after several trials and tribulations come to a conclusion.  We are using the MVVM (Model-View-ViewModel) pattern and what I have done was create a ViewModel class which exposes properties (while performing some business logic under the hood) that are meant to be bound to controls in the XAML.

    A shell (empty) Silverlight class library is created using the ViewModel interface (nothing is done under the hood) and the class library is added as a reference to the Expression Blend project.  Our Expression Blend users can then set on the main page a DataContext of the ViewModel as a CLR data binding.  Then, when actually creating the bindings to all the controls on the page, they choose "Explicit DataContext" which shows all of the properties that they can choose from to tie to that particular control.

    The end result is XAML which: a) adds a resource to the page to create an instance of the ViewModel (which the developers actually remove from the XAML); and b) all the remaining bindings to those properties "just work" when the XAML is processed in the development project with a ViewModel that implements the same interface (properties, etc.) but exhibits the correct business logic, communicates with WCF services, etc.  A very good separation of the UI from the actual code behind.

    The XAML is just text --as long as Blend creates the same 'Binding' paths on a 'dummy' class library CLR object that match the same as the production class library objects (and we remove the StaticResource that Blend added to the resources), then it works just swimmingly.

    I know this is almost three months later since your post (and four since mine), but I think that after delving in further, putting things into practice (i.e. suffering trials and tribulations) I can finally see how things are evolving.  One question I have left yet is behaviors....  however, that will be up to a new post.

    Cheers,

    Joe
    • Marked as answer by JFalcon Friday, December 18, 2009 4:53 AM
    Friday, December 18, 2009 4:51 AM