v3.6.2 Light CslaDataProvider InvokeMethod commanding

v3.6.2 Light CslaDataProvider InvokeMethod commanding

Old forum URL: forums.lhotka.net/forums/t/6845.aspx


davido_xml posted on Friday, April 24, 2009

I like the idea of having as little code behind as possible. I would like to use the CslaDataProvider and the attached properties of InvokeMethod as much as possible.

I need to provide "follow up" functionality i.e. a user is viewing a widget the following buttons are visible New, Save, Cancel, Delete and Follow Up. Clicking Follow Up will create a new widget based on the current widget but will default some parameters.

I can see how to use the attached properties of InvokeMethod for Save and Cancel. For the other operations I am using event handlers in code behind. Is there a way I can avoid the code behind? Should I derive from CslaDataProvider and create my own DataProvider with my own commands?  I am not concerned with the Delete operation at the moment. The follow up finds the appropriate data portal method via method overloading.

FollowUpButtonClick

CslaDataProvider expenseProvider = this.Resources["ExpenseData"] as CslaDataProvider;
   if (expenseProvider != null)
   {
    expenseProvider.FactoryParameters.Clear();
    XXX.Business.BusinessClasses.Expense exp =
     expenseProvider.Data as XXX.Business.BusinessClasses.Expense;

    expenseProvider.FactoryParameters.Add(exp);
    expenseProvider.FactoryMethod = "CreateExpense";
    expenseProvider.Refresh();
   }

 

NewButtonClick

CslaDataProvider expenseProvider = this.Resources["ExpenseData"] as CslaDataProvider;

if (expenseProvider != null)

{expenseProvider.FactoryParameters.Clear();

expenseProvider.FactoryMethod = "CreateExpense";

expenseProvider.Refresh();}

Thanks

RockfordLhotka replied on Friday, April 24, 2009

I would look into creating a subclass of CslaDataProvider.

One of the major advantages of the approach we took in Silverlight, with InvokeMethod and the CslaDataProvider, is that you can treat the data provider control pretty much like the current (very trendy) view-model concept.

That means the data provider is an object that exposes the model (your object), and a set of commands that can be executed on or around that model. The CslaDataProvider already provides a set of standard commands, and you can add more by subclassing.

Unfortunately I haven't actually tried this - but the concept is sound, and it is a direction I want to support.

When SL3 comes out and we can do relative binding, we should be able to alter InvokeMethod so it can target any object, not just resources, and that'll make it work even better with the MVVM scenarios (with or without the CslaDataProvider - though I personally really do like the data provider approach).

Copyright (c) Marimer LLC