CSLA 3.8 - how to generically reference ViewModel.IsBusy

Because then my generic toolbar is linked to a specific VM that I have to maintain a reference to in XAML.  Currently my toolbar is generated dynamically based on available child data and user permissions.

My toolbar is a ItemsControl with itemsSource of my ParentVM.ToolbarItemsBOCollection.  I don't have the link between ChildCslaVM and toolbarItem in the UI. 

So the parent VM constructs a toolbar based on which access the user has and then loads/fetches the child CslaVM<T> either on demand or upfront.

I already have a slew of ShowXyz and CanXyz for each of the buttons in the toolbar.  I don't want to maintain another set of IsBusyXyz properties.

What I wanted to do is in my loop where I build the available toolbar buttons I can link the toolbarItemVM to the CslaVM<T>.

I'm now leaning more to the reverse solution where the toolbarButtonVM is also a child of the CslaVM.

Why wouldn't you just bind the UX element(s) to the property?

It sounds like you are trying to control the UX through code - but XAML is really designed to go the other way, to have the UX use binding to respond to properties without you writing code.

Certainly that's what ViewModel is designed to support.

I can see your point ...  but am I really generating the UI?  It is sort of a mix between exposed UserAccess and ChildBOExplorer.

I could generate the same info from an array of childViewModelBO's which maybe is what I should do...

Each ChildBO is to be viewed in a separate view by clicking on a toolbar button.  My toolbar is collection of BOs that represent what the childmodel type is (enum), if I should allow user access (IsEnabled/IsVisible) + IsBusy.

I struggled with where to put the logic to show/hide the views and that is really the only 'presenter' part I think.  I'm not happy with these CanShowXyz properties in my ViewModel but it isn't that terrible.  I think actually as I type this I can move those into the childModels and trigger of the databound IsChecked on my toolbar.

If it wasn't called ToolBarItem but ChildViewModel would it still feel so dirty ?

Maybe I should ditch the toolBarItem BO and make it an interface in my childVMs.  Then I introduce a ChildVM collection to my ViewModel to expose the interface properties?

What I don't want to have is umpteen extra pieces just to 'totally comply'.

I started with Prism, ripped it all out, and looks like I'm slowly moving back towards that again.

I know something feels off as I had issues just trying to decide which assembly I should put another base class into and it was feeling "wrong".

ie)

CSLA.ViewModel<T>

Agc.AgcViewModel<T>  - my Corp Library (Abstract)

Epm.EpmViewModel<T> - my app library (Abstract)

Epm.SharedUI.EpmViewModelBase<T> - an overload to include my reference to a EpmToolBarItemVM

I appreciate your feedback

Thanks

jack

This may be too esoteric, but I'll throw it out anyway.

I think you may be violating the principles of the MVVM pattern. A viewmodel object should be relatively decoupled from the view - and generating aspects of the view is pretty tightly coupled.

I'd suggest you consider that the UX generation concepts should be in some other actor than the viewmodel. The viewmodel actor is really responsible for supporting the UX in an abstract manner. Actually creating the UX is a different job/responsibility, and therefore should be handled by some other actor.

I've started using presenter classes along with viewmodel classes. Use the presenters to handle more tightly-coupled UX concerns like navigation, thereby keeping the viewmodel classes much more decoupled and focused on business processing behind the form, rather than on the form itself.