<ListBox x:Name="MyListBox" ItemsSource="{Binding Path=Model}"
ItemTemplate="{StaticResource DataList}"
csla:InvokeMethod.TriggerEvent="SelectionChanged"
csla:InvokeMethod.Resource="{StaticResource ListModel}"
csla:InvokeMethod.MethodName="ShowItem"
csla:InvokeMethod.MethodParameter="{Binding SelectedItem, ElementName=MyListBox}"/>
for your pseudocode of:
<ListBox ItemsSource="{Binding Path=Model}"
ItemTemplate="{StaticResource DataList}"
csla:InvokeMethod.TriggerEvent="SelectionChanged"
csla:InvokeMethod.Resource="{StaticResource ListModel}"
csla:InvokeMethod.MethodName="ShowItem"
csla:InvokeMethod.MethodParameter="{Element.SelectedItem}"/>
That was my morning post, after which I spent time working on the problem. At the core of the issue (as I suspected) is that the SL2 controls in Csla.Silverlight need updating to take advantage of the SL3 features.
So in fact it all works very nicely now that I've reworked InvokeMethod somewhat.
<ListBox ItemsSource="{Binding Path=Model}"
ItemTemplate="{StaticResource DataList}"
csla:InvokeMethod.TriggerEvent="SelectionChanged"
csla:InvokeMethod.Target="{Binding}"
csla:InvokeMethod.MethodName="ShowItem"
csla:InvokeMethod.MethodParameter=
"{Binding SelectedItem, RelativeSource={RelativeSource Self}}"
csla:InvokeMethod.ManualEnableControl="True" />
And the ShowItem() method accepts a single parameter which is the selected item value from the ListBox.
This even works with multiselect, because you can bind MethodParameter to SelectedItems and a list of selected items is passed into ShowItem().
I made this all work in WPF too, even though arguably commanding is the better solution. But I say arguably, because InvokeMethod is more flexible than commanding, and I think the result is somewhat simpler code.
Couple of rambling Saturday morning thoughts:
1) Without sounding ignorant because I haven't spent much time looking into them but could this now be wrapped up as a behavior CslaSelectionChangedBehavior that eliminated having to replicate all this code for each control? Really it is all the same code except for the method=ShowItem line. You could even get rid of that if you defaulted the methodName to the "ControlNameSelectionChangedSelectedItem()"
2) My other thought is forgetting about behaviours and just exending the InvokeMethod to remove some of the redundant lines of code. It could be coupled with an ICslaModelInvokeShortcuts so that the model would always implement the expected functionality or more importantly the correct format or all the required extra objects (say a CslaModelProvider in your VM).
Anyhow, could this not lead to
<ListBox ItemsSource="{Binding Path=Model}" ItemTemplate="{StaticResource DataList}"
csla:InvokeSelectionChangedMethod.MethodName="ShowItem"/>
I don't know how the InvokeSelectionChangedMethod actually gets the other arguments but it would be nice if they could just be derived from the InvokeSelectionChanged implementation.
3) It would be pretty cool if your CSLA implementations of the InvokeMethod or behaviors or whatever was built around an plan for an extensible library. I know you were disappointed with people complaining about the set of standard rules (email example) but if you put together the basics and made it easy to plug in, refactor, and override I think we could easily have a nice CSLA community set of behaviors and addins. It would certainly take a lot of the fear out of many people looking to leap from WinForms to an XAML implementation and having to wonder how on earth to do anything without using the dreaded codebehind.
I could see add-ons that let Sergey provide a SaveAs behavior that could be linked to a button and triggers off his local database in isolated storage functionality to directly save a CSLA BO.
Is this starting to sound like the CslaUIFramework you said you would never tackle?
Jack
I think that's the broad idea behind MVVM - you can create a VM object that provides actions and data for your View and mediates interactions with the Model.
If the View is pure XAML (my goal anyway) and the Model is a CSLA business object (again, my goal), then the ViewModel needs to do at least two things:
But real business forms often need more than one business object (at least to populate combobox controls). So in reality, the VM must be able to load and expose multiple Model objects to meet the needs of the View.
Beyond that, the VM must provide a set of actions, and possibly other data, required by the View.
I'm focusing on the actions, which would (in my view) be simple methods that can be invoked when something happens in the View.
So that's what InvokeMethod does - it is triggered by an event in the View, and it invokes a simple method in the VM.
Now you could create a UI framework around that - very probably by creating one or more VM base classes that expose different common actions.
I have a simple CslaViewModel<T> base class, for example, that exposes one Model and implements basic Save, Cancel, AddNew, Remove and Delete actions. Everything you get from CslaDataProvider in Silverlight actually.
As always with CSLA, I only write enough UI goo to enable key scenarios. Creating and maintaining a UI framework is a full-time project on its own, so if I decided to do that it is a certainty that CSLA would suffer for it.
From what I gather, there are numerous alternatives to InvokeMethod out there. I'm sure many/most will work with CSLA objects. So I don't feel real pressured to make the ultimate solution here. However, I do feel pressured to make the minimum solution necessary to create a basic UI entirely with CSLA - and that's what I'm driving at with these changes.
Rocky,
I think it would be very beneficial, at least to me, to see
examples that do in fact implement the realities of multiple models. While
you are not providing a standard and there are a dozen ways to do anything,
your direction and how it relates to CSLA, is very much appreciated.
One think I have done within the Silverlight.Fx framework is exposing
child models from my ViewModel via databinding. So essentially the
DataContext of the view is the CoreViewModel and then I databind to the other
models when I need them (say I want to open a form that has its own ViewModel).
As per our earlier thread I exposed a single dataprovider as a property in my ViewModel
baseClass that I'm essentially using to manage the DataPortal actions and the
CanXYZ methods so I think your implementation is going to be great for me.
I'm quite happy with it but I'm still struggling a little bit
with large composite views and how best to manage those. I think the
reality is I made my BO's a bit to big with a giant master/parent and then
umpteen children. But we'll see how that all refactors out as I learn and
better understand more.
The one big thing I have really really struggled with respect to
MVVM is the manner in which to handle confirmation messages and getting direct
feedback from the user. The simple example being a user wants to delete
some important data and I want to make them confirm.
The simple way is codebehind on the click, get the response, and
then re-engage the ViewModel to finish the job. I think what I need to
start doing is building some generic behaviors or implementing some ActionConfirm+Action
in one step vs. just Action to the ViewModel and then the viewModel deciding
that it needs to confirm or not.
It can be difficult to state that a ConfirmationRequest is a BusinessRule
or a UI rule.
If it is a business rule then I should expose it as a property?
Maybe I can start adding a 'CanActionWithoutConfirm' property here and there
but that starts to feel like a lot of extra effort.
If it is a UI rule then who should manage it ? the View or
the ViewModel? If it's the View then how to do it without code behind
which ultimately involves the ViewModel etc. etc.
I'm really curious how you plan to tackle that in your LOB
implementations.
jack
From: RockfordLhotka [mailto:cslanet@lhotka.net]
Sent: August-01-09 1:40 PM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] CSLA MVVM Blog Post
I think that's the broad idea behind MVVM - you can create a VM object that
provides actions and data for your View and mediates interactions with the
Model.
If the View is pure XAML (my goal anyway) and the Model is a CSLA business
object (again, my goal), then the ViewModel needs to do at least two things:
But real business forms often need more than one business object (at least
to populate combobox controls). So in reality, the VM must be able to load and
expose multiple Model objects to meet the needs of the View.
Beyond that, the VM must provide a set of actions, and possibly other data,
required by the View.
I'm focusing on the actions, which would (in my view) be simple methods that
can be invoked when something happens in the View.
So that's what InvokeMethod does - it is triggered by an event in the View,
and it invokes a simple method in the VM.
Now you could create a UI framework around that - very probably by creating
one or more VM base classes that expose different common actions.
I have a simple CslaViewModel<T> base class, for example, that exposes
one Model and implements basic Save, Cancel, AddNew, Remove and Delete actions.
Everything you get from CslaDataProvider in Silverlight actually.
As always with CSLA, I only write enough UI goo to enable key scenarios.
Creating and maintaining a UI framework is a full-time project on its own, so
if I decided to do that it is a certainty that CSLA would suffer for it.
From what I gather, there are numerous alternatives to InvokeMethod out
there. I'm sure many/most will work with CSLA objects. So I don't feel real
pressured to make the ultimate solution here. However, I do feel pressured to
make the minimum solution necessary to create a basic UI entirely with
CSLA - and that's what I'm driving at with these changes.
Confirmation is a UI rule. I feel comfortable saying that,
because if you consider that the interface might be an XML service, where would
the concept of “confirmation” fit in?
If you tell me that it still fits in, then you are telling me
that you have a multi-step workflow requirement, and that’s fine, but is
quite a different thing than a standard CRUD-type scenario that happens to have
a confirmation dialog.
Does that make sense?
So for the 99.9% case, confirmation is a UI rule.
And in a MVVM world, the View has no code (in my view), so any
UI behaviors occur thanks to the VM. Since the VM is part of the presentation
layer, there’s absolutely no problem with having the VM pop up a dialog. It
isn’t really any different from the VM navigating the user to a different
View (and associated VM).
Okay I agree and can live with that statement. Where it gets
tricky is how does the VM popup a dialog? (very similar to you previous
email about showForm).
With navigation I'm setting a URI property on a UI control that swaps
its content and it is more of a one way action. Sure I can go back if I
have a pageCache or something but the original view has no role.
With a Dialog I need to show something visual, get it some
data, get a response, get the response back to the VM, and then do something.
Also with a Dialog you want it to be totally generic so you only
have to worry about a type of dialog (alert/question/confirm) and then some
text and a result type.
I'm really trying to improve my UI's so that dialog boxes don't
really exist but there is a lot of extra effort involved there and really a
popup with some child data telling the parent to refresh after closing is almost
the same scenario.
From: Rockford Lhotka [mailto:cslanet@lhotka.net]
Sent: August-01-09 2:44 PM
To: jaddington@alexandergracie.com
Subject: RE: [CSLA .NET] CSLA MVVM Blog Post
Confirmation is a UI rule. I feel comfortable saying that,
because if you consider that the interface might be an XML service, where would
the concept of “confirmation” fit in?
If you tell me that it still fits in, then you are telling me that
you have a multi-step workflow requirement, and that’s fine, but is quite
a different thing than a standard CRUD-type scenario that happens to have a
confirmation dialog.
Does that make sense?
So for the 99.9% case, confirmation is a UI rule.
And in a MVVM world, the View has no code (in my view), so any
UI behaviors occur thanks to the VM. Since the VM is part of the presentation
layer, there’s absolutely no problem with having the VM pop up a dialog.
It isn’t really any different from the VM navigating the user to a
different View (and associated VM).
Hi,
I think this discussion of possible MVVM implementations strategies with CSLA seems to be on the right track! We are currently working on an online banking application for private financial management and the UI processes are pretty complex and need to provide different views and editable capabilities on business entities including transactional update/cancel/undo functionality. Following I would like to outline our approach which mirrors some of the points above and probably solved some the problems mentioned above.
We use CSLA for our business layer and PRISM for the interface implementation strategy. We try to force the “ViewModel first” principle. We are not 100% there - but soon. And we also tried to force no code behind. But there are certain cases were we need to call back in to the UI, like Jack mentioned (things like QueryForSave() before we call the DataPortal etc.). To wire everything together we have implemented a ViewMode Interface IBusinessEntityViewMode<TEntity> and IBusinessEntityCollectionViewModel<TCollection, TEntity>. TEntity is derived from IBusinessEntity and TCollection is derived from IBusinessEntityList.
public interface IBusinessEntity :
IAuthorizeReadWrite,
IMobileObject
IEditableBusinessObject,
IParent,
ICloneable,
ISavable,
INotifyChildChanged,
INotifyPropertyChanged,
ISerializationNotification,
INotifyPropertyChanging
{
bool IsSelected { get; set; }
event EventHandler SelectedChanged;
}
public interface
IBusinessEntityList<ContainingEntityType> :
IExtendedBindingList,
INotifyBusy,
IMobileObject,
IEditableCollection,
IUndoableObject,
ISavable,
IParent,
INotifyBusy,
INotifyChildChanged,
IEnumerable<ContainingEntityType>
where ContainingEntityType : IBusinessEntity
{
}
}
You will have noticed that these Interfaces are all implemented by BusinessBase and BusinessListBase of CSLA.
And here is corresponding interface of our ViewModel every Business-Developer needs to implement and should write Unit tests for:
public interface IBusinessEntityCollectionViewModel<TSetType, TType>
: INotifyPropertyChanged
where TSetType : IBusinessEntitySet<TType>
where TType : IBusinessEntity
{
event Action<object> OnLoadedEvent;
event Action<TType> OnSavedEvent;
event Action<TType> OnCanceledEvent;
event Action<TType> OnRemovedItemEvent;
DelegateCommand<TType> CancelCommand { get; set; }
DelegateCommand<TType> UndoCommand { get; set; }
DelegateCommand<object> LoadCommand { get; set; }
DelegateCommand<TType> SaveCommand { get; set; }
DelegateCommand<TType> RemoveItemCommand { get; set; }
void RemoveItem(TType item);
bool CanRemoveItem(TType item);
bool CanSave(TType arg);
void Save(TType arg);
// arg can any type…
bool CanLoad(object arg);
void Load(object arg);
void Cancel(TType arg);
bool CanCancel(TType arg);
void Undo(TType arg);
bool CanUndo(TType arg);
TSetType Model { get; set; }
IList<TType> SelectedEntities { get; }
}
The DelegateCommand<T> was taken from PRISM.
One additional property we needed was the IsSelected property on an IBusinessEntity. Not for identifying the selected entities (this is can also be done through the SelectedEntites Collection of the IBusinessEntitySetViewModel) but more importantly in situations where only the ViewModel or the Entity itself has to determine which Entities need to be selected (after Save operation or after sort operations). If this property is bound to the IsSelected DependencyProperty of the ItemsControls in XAML it visuals the selection in the view and fires the SelectedItemsChanged event on the Selector-Control and so syncs up the ViewModel again.
The strategy how we “load” ViewModels was taken from Eric Van Der Walk’s great and lightweight ApplicationUseCase Model Framework he wrote on top of PRISM to implement “Outlook Style Applications” (btw a very interesting approach to implement flexible and pluggable Outlook-like applications with PRISM). http://blogs.msdn.com/erwinvandervalk/archive/2009/03/02/how-to-build-an-outlook-style-application.aspx and http://blogs.msdn.com/erwinvandervalk/archive/2009/04/29/how-to-build-an-outlook-style-application-with-prism-v2-part-2.aspx
One of his core framework classes is the “ModelVisualizer” (a UserControl derived from ContentControl) and a class called “ViewModelRegistry” (he also needed to add and replace some of PRISMs behaviors to integrate it smoothly into PRISM). With it you are able to “register” ViewModel types (or instances) with a Region (not view types as with standard PRISM).
//somewhere in the initalization code…
modelVisualizationRegistry.Register<EmailToolBarViewModel, EmailToolBar>();
ViewToRegionBinder.Add("ToolbarRegion", this.emailToolBarViewModel);
If PRISM finds a Region where a ViewModel was registered for, he
1. creates a ModelVisualizer-Control,
2. instantiates the View and ViewModel (by using Microsofts Unity Ioc container),
3. assigns the ViewModel instance to the DataContext Property of the View
4. assigns the View to its Content property
5. and finally adds itself to the ItemsSource of the ItemsControl where the Region was attached to.
We extended his implementation a little to support our above ViewModel-Interface. So it fires the LoadCommand where the BusinessEntities- LoadHandler implements how to load the Entities from the DataPortal and assigns it the the Model property of the ViewModel Interface.
In XAML we have to decide which SelectionMode triggers the SelectedEntitiesChanged event to the ViewModel:
<ItemsControl .... BusinessEntitySetViewModel.SelectionMode=”Click” ..../>
Other SelectionMode options we needed are “DoubleClick”, “Enter” and “DoubleClickEnter”. This Attached Property wires up the right event handlers and makes sure that the SelectedEntities Collection is filled and the SelectetEntitiiesChanged Event of the ViewModel is fired.
All what we implemented so far works pretty good with simple and complex UI processes and as more use case we are implementing the maturity and stability of this approach grows continuously. So I am looking forward on what this discussion will bring up in the future and probably in terms of additional CSLA framework classes supporting MVVM ;-)
Andreas
I refactored ProjectTracker to work with PRISM and Eric's ApplicationUseCase model. Before I can post it I have to eliminate some of my internal test cases. It should work with WPF and Silverlight 3. I will come back to this thread when ready (probably in the next two or three weeks) and then can email it to you.
I am happy to make you a contributor to CSLAcontrib on codeplex
if you’d like to put the code up there for people to use.
Rocky
From: Andreas
[mailto:cslanet@lhotka.net]
Sent: Tuesday, August 04, 2009 7:17 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: CSLA MVVM Blog Post
I refactored ProjectTracker to work with PRISM and
Eric's ApplicationUseCase model. Before I
can post it I have to eliminate some of my internal test
cases. It should work with WPF and Silverlight 3. I will come
back to this thread when ready (probably in the next two or three weeks) and
then can email it to you.
Andreas:
Yes, I will. Andreas
That's wonderful, thank you!
Just email me your account name on CodePlex and I can add you as a contributor.
I didn't had enough spare time to cleanup everything but I am pretty close now. Hope to finish everything by beginning of next week.
Andreas
Finally I finished PTP (ProjectTracker for PRISM).
I restructured the source code a little so that PTP is fully MVVM based with “ZERO” Code Behind. To understand the structure one need to have a good understanding of PRISM (Composite Application Library for WPF and Silverlight, http://compositewpf.codeplex.com/) and Erwin van der Walk’s smart, lightweight and very powerful “Outlook Style Prism” Framework which sits on top of PRISM: http://blogs.msdn.com/erwinvandervalk/archive/2009/03/02/how-to-build-an-outlook-style-application.aspx
There are still some small missing pieces that I will add soon (like busy animations etc.). The next step will be to implement a Tabed-layout for the “MainRegion”, so that all modules can be selected via tab or "outlook bar style buttons" and thanh a port to Silverlight 3 (huuuch).
I will upload the source as part of the ProjectTracker sample project to Codplex Csla Contrib project as soon as Rocky lets me in.
Hi
Rocky!
Finally
I finished PTP (ProjectTracker for PRISM).
I
restructured the source code a little so that PTP is fully MVVM based with
“ZERO” Code Behind. To understand the structure one need to have a
good understanding of PRISM (Composite Application Library for WPF and
Silverlight, http://compositewpf.codeplex.com/)
and Erwin van der Walk’s smart, lightweight and very powerful
“Outlook Style Prism” Framework which sits on top of PRISM: http://blogs.msdn.com/erwinvandervalk/archive/2009/03/02/how-to-build-an-outlook-style-application.aspx
There
are still some small missing pieces that I will add soon (like busy animations
etc.). The next step will be to implement a Tabed-layout for the
“MainRegion”, so that all modules can be selected via tab or
outlook bar buttons. The next step is a port to Silverlight 3 (huuuch)
My
Codplex username ist “AndyK”.
I
am not sure how to handle the source code. Currently I’ve added a solution
folder to the ProjectTracker sample solution, because it uses its infrastructure.
I also think that’s the best way to deploy it because user can easily compare
it with the original version. What do you think?
Regards,
Andreas
Von: Rockford Lhotka
[mailto:cslanet@lhotka.net]
Gesendet: Dienstag, 4. August 2009 17:14
An: Kuhlmann Andreas
Betreff: RE: [CSLA .NET] RE: CSLA MVVM Blog Post
I am happy to make you a contributor to CSLAcontrib on codeplex
if you’d like to put the code up there for people to use.
Rocky
From: Andreas [mailto:cslanet@lhotka.net]
Sent: Tuesday, August 04, 2009 7:17 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: CSLA MVVM Blog Post
I refactored ProjectTracker
to work with PRISM and
Eric's ApplicationUseCase model. Before I
can post it I have to eliminate some of my internal test cases. It
should work with WPF and Silverlight 3. I will come back to this
thread when ready (probably in the next two or three weeks) and then can email
it to you.
BUHL DATA SERVICE GMBH
Am Siebertsweiher 3/5
D-57290 Neunkirchen
Geschäftsführer: Martin Buhl & Peter Glowick
Handelsregister: AG Siegen, HRB 3015
I’ve added you to cslacontrib.
Please coordinate with jonnybee, as he’s managing the
cslacontrib project and overall structure and can help you figure out how/where
to put the code.
Thank you!
Rocky
From: Kuhlmann Andreas
[mailto:cslanet@lhotka.net]
Sent: Wednesday, September 09, 2009 7:09 AM
To: rocky@lhotka.net
Subject: [CSLA .NET] PTP: ProjectTracker for PRISM
Hi Rocky!
Finally I
finished PTP (ProjectTracker for PRISM).
I
restructured the source code a little so that PTP is fully MVVM based with
“ZERO” Code Behind. To understand the structure one need to have a good
understanding of PRISM (Composite Application Library for WPF and Silverlight,
http://compositewpf.codeplex.com/)
and Erwin van der Walk’s smart, lightweight and very powerful “Outlook Style
Prism” Framework which sits on top of PRISM: http://blogs.msdn.com/erwinvandervalk/archive/2009/03/02/how-to-build-an-outlook-style-application.aspx
There are
still some small missing pieces that I will add soon (like busy animations
etc.). The next step will be to implement a Tabed-layout for the “MainRegion”,
so that all modules can be selected via tab or outlook bar buttons. The next
step is a port to Silverlight 3 (huuuch)
My Codplex
username ist “AndyK”.
I am not
sure how to handle the source code. Currently I’ve added a solution folder to
the ProjectTracker sample solution, because it uses its infrastructure. I also
think that’s the best way to deploy it because user can easily compare it with
the original version. What do you think?
Regards,
Andreas
You can download the source here:
http://cslacontrib.codeplex.com/SourceControl/ListDownloadableCommits.aspx
Click on the Download link. Right hand in the "Lastest Version" section.
In terms of additional CSLA classes to support MVVM, I am open
to suggestions – keeping in mind that my philosophy with CSLA is that it
is a business layer (Model) framework, and only fills in the minimum gaps
necessary to play well with Visual Studio data binding models.
Of course right now there is no MVVM support in Visual Studio,
and we might have to wait until 2011 or 2012 to see any – so anything we
do now is speculation…
But if it is good speculation – if I can do things that are
likely to simplify working with whatever Microsoft does support in the future –
that’s the game, and that’s good stuff.
To answer your question on "how does the VM popup a dialog", I went with the addage, 'Sometimes you just need to get work done'. Rather than twist myself into knots trying to do a simple dialog the pure MVVM way (is there a pure way anyways?), I went back to the reason for doing the MVVM pattern; testability. So I wanted a dialog that could work in two modes; interactive for UI use, and non-interactive for testing.
Karl Shifflett came up with a custom dialog that does just that. If you go to his blog you can download the materials from his recent MVVM teaching tour and get the source code for it there. Works a charm, looks slick, gets the job done simply.
To follow up to my own reply though…
My biggest struggle at the moment, with MVVM and zero
code-behind, is loading a new form.
Consider a scenario where I’m on a List of Customers
form. The user double-clicks a customer in the list and I use InvokeMethod to
call ShowCustomer(), passing the CustomerInfo object as a parameter. So far so
good.
But ShowCustomer() needs to navigate me to another form. That
means creating a new UserControl (the CustomerDetail form) and providing it
with enough information so that form can render itself – probably the
CustomerInfo.Id property or something.
The trick then, is how does the CustomerDetail form, or its
ViewModel object, get this Id value? If I pass it to the form, that means
creating a constructor overload in the form and that’s code-behind. Oops.
If I create a ViewModel and pass it the Id, that’s OK, that’s not
code-behind, but now who’s creating CustomerDetail, and more importantly,
how does it get access to this new ViewModel object without code-behind?
If I’m willing to have a custom UserControl base class I can
streamline this to some degree, but that way leads to the slippery slope of a
UI framework, and imposes a burden on the XAML designer person, because their
XAML needs to use this custom base type. A tall order for pure XAML-slingers.
I don't see a way without a custom UserControl Base that can
either receive the model via its constructor or you can pass it via DataBinding.
That other FX UI framework does just that with a custom View control. I
would open a new form by using the ShowForm action which has two DependencyProperties
FormType and FormModel.
What I have done, in your CustomerDetail model, is to have a
CustomerDetailVM in my ViewModel. I expose it as a property and in the
Get accessor I would either instatiate it or modify it to put my current data into
it. This means of course your VM must know which Customer is currently
selected.
So you end up with:
CusterListViewModel{
int
SelectedCustomerId {get;set;}
private
CustomerDetailViewModel _customerDetailVM
public
CustomerDetailViewModel CustomerDetailVM
{
get
{
if(_customerDetailVM
== null) _customerDetailVM = new CustomerDetailVM() { p1,p2, set any defaults...
};
_customerDetailVM.CustomerDetailId
= SelectedCustomerID
}
}
}
Then the XAML is <ActionShowForm FormType="CustomerDetailForm"
FormModel="{Binding CustomerDetailVM}">
Depending on what my child form needs I have either passed just
the Id and let the childForm get the data when Binding occurs or I just replace
SelectedCustomerId with SelectedChildBO and pass the whole child.
Bottomline though there is a UserControl that lets me pass in
the ViewModel to the new form via the constructor or I can databind to it because
the Model is exposed as a DependencyProperty and then the DataContext is set to
that Model.
I'm currently trying to determine the best way to modify the
ActionShowForm so that I can trigger a method on my ViewModel once the FormCloses.
From: Rockford Lhotka [mailto:cslanet@lhotka.net]
Sent: August-01-09 2:50 PM
To: jaddington@alexandergracie.com
Subject: RE: [CSLA .NET] CSLA MVVM Blog Post
To follow up to my own reply though…
My biggest struggle at the moment, with MVVM and zero
code-behind, is loading a new form.
Consider a scenario where I’m on a List of Customers
form. The user double-clicks a customer in the list and I use InvokeMethod to
call ShowCustomer(), passing the CustomerInfo object as a parameter. So far so
good.
But ShowCustomer() needs to navigate me to another form. That
means creating a new UserControl (the CustomerDetail form) and providing it
with enough information so that form can render itself – probably the
CustomerInfo.Id property or something.
The trick then, is how does the CustomerDetail form, or its
ViewModel object, get this Id value? If I pass it to the form, that means
creating a constructor overload in the form and that’s code-behind. Oops.
If I create a ViewModel and pass it the Id, that’s OK, that’s not
code-behind, but now who’s creating CustomerDetail, and more importantly,
how does it get access to this new ViewModel object without code-behind?
If I’m willing to have a custom UserControl base class I
can streamline this to some degree, but that way leads to the slippery slope of
a UI framework, and imposes a burden on the XAML designer person, because their
XAML needs to use this custom base type. A tall order for pure XAML-slingers.
Hi Rocky,
Forgive the probable naiveness; but where can I find the CslaViewModel<T> class that you referred to ?
Hi Rocky,
We are using CSLA for an application and are currently architecting the UI framework...
We were looking at leveraging the composite app features provided by Prism along with a suitable pattern that separates concerns betwen the UI layout and logic. Most of the guidances/suggestions regarding WPF UI patterns focus on the MVVM[or a variant(?) thereof, such as MVP].
As of now, we are thinking of using the tools provided by CSLA for WPF and fitting them into the MVVM pattern, so that we maximise the usage of what is available 'in the box'. It is in this direction that your mention of the 'CslaViewModel<T>' class seemed to be of particular interest.
Any guidance on how to forward on this would be invaluable...
Thanks in advance...
I think some UI framework is important for any application –
web, Windows Forms or XAML. The unique characteristics of XAML and its binding infrastructure
seem to leave MVC and MVP (in their traditional forms) out in the cold.
I’ve never thought they worked well in Windows Forms for
the same reason – they don’t exploit data binding well. But XAML
takes that to a whole new level.
The MVVM “pattern” is a potential model on which to
build a UI framework that does exploit the XAML binding feature. In my work
with the pattern (and in discussions in person and via my blog) it has become
clear to me that MVVM is very nebulous, and that its goals don’t include
reduction of code or simplicity – two goals I value highly at all times. So
my attitude toward MVVM is not real positive at the moment, since I don’t
want something that increases my coding work (especially in the UI) and that
doesn’t decrease complexity.
At the same time, MVVM feels correct – at least the
underlying principles of the pattern feel right to me. I just think the trick
is to figure out a way to go where the pattern wants to go, but in a way that
does reduce code and complexity.
So my experiments with the Csla.Silverlight.ViewModel<T>
class (in 3.8) are around enabling something like MVVM (or maybe MVVM itself –
depends on who’s interpretation of the pattern you listen to :) )
Personally I think I’m implementing MVVM, but with some extra goals
around code reduction and simplicity – if I can get it to work nicely.
What isn’t entirely known at this point, is what kind of
designer support or constraints Visual Studio 2010 will impose (or enable). Those
concerns will be for CSLA .NET 4.0, not 3.8.
Rocky
From: prasnair
[mailto:cslanet@lhotka.net]
Sent: Wednesday, August 19, 2009 7:19 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] CSLA MVVM Blog Post
Hi Rocky,
We are using CSLA for an application and are currently architecting the UI
framework...
We were looking at leveraging the composite app features provided by Prism
along with a suitable pattern that separates concerns betwen the UI layout and
logic. Most of the guidances/suggestions regarding WPF UI patterns focus on the
MVVM[or a variant(?) thereof, such as MVP].
As of now, we are thinking of using the tools provided by CSLA for WPF and
fitting them into the MVVM pattern, so that we maximise the usage of what is
available 'in the box'. It is in this direction that your mention of the
'CslaViewModel<T>' class seemed to be of particular interest.
Any guidance on how to forward on this would be invaluable...
Thanks in advance...
Copyright (c) Marimer LLC