CSLA 3.8 - how to generically reference ViewModel.IsBusy

CSLA 3.8 - how to generically reference ViewModel.IsBusy

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


Jack posted on Tuesday, November 10, 2009

Rocky,

I've got a toolbar/menu like BO that is databound for navigation.  One particular underlying BO is very slow to load so I wanted to visually show that on the toolbar button either as a different icon or the spinning animated IsBusy or even disable the button.

Anyhow I have number of ViewModels associated with the buttons but they are defined as MyViewModel<T> so I'm having issues trying to generically referencing their IsBusy property.  ie) Cast my specific VMs to a common base class.

I can link the VM as an object to the toolbarItemBO but I can't get any further than that other than just using reflection to see if their exists an IsBusy property and then I could check it.

I suppose I could also watch for propertyChanged but that seems like more effort.

Is that really the only option or is there a way to get around that? 

Thanks

jack

Jack replied on Tuesday, November 10, 2009

Of course I suppose I could also do it the other way - and link the buttonBO to the MyViewModel<T> base class and then expose the button IsBusy to the viewModel.  Then I can code a single OnPropertyChanged event...

Maybe that is a better approach?

Thanks

jack

RockfordLhotka replied on Tuesday, November 10, 2009

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.

Jack replied on Tuesday, November 10, 2009

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.

 

From: RockfordLhotka [mailto:cslanet@lhotka.net]
Sent: November-10-09 10:42 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] CSLA 3.8 - how to generically reference ViewModel.IsBusy

 

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.



RockfordLhotka replied on Tuesday, November 10, 2009

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.

Jack replied on Tuesday, November 10, 2009

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

 

 

From: RockfordLhotka [mailto:cslanet@lhotka.net]
Sent: November-10-09 1:22 PM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] CSLA 3.8 - how to generically reference ViewModel.IsBusy

 

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.



RockfordLhotka replied on Tuesday, November 10, 2009

I don't think MVVM is the entire solution for a XAML UI framework. I think it is just one part of the puzzle.

I suspect you could combine MVC and MVVM to get a good result. I started researching this, but got sidetracked by some other work.

The thing about MVC is that the acronym is misleading. MVC actually consists of 4 parts, not 3:

  1. Model
  2. View
  3. Controller
  4. Runtime

Nobody seems to talk about the runtime, but something needs to actually invoke the Controller and render the View returned from the Controller. In ASP.NET MVC this is ASP.NET MVC itself - the MVC runtime.

If you just open a WPF or Silverlight project, you have no runtime comparable to what the ASP.NET MVC runtime does for you. And you must have something in your app who's job it is to invoke the Controller and put the resulting View on the screen. And to take command messages (like postback calls in the web) and route them to the correct method on the correct controller.

So this runtime really does two things: renders views, and routes messages to controllers. I rather suspect therefore, that the runtime consists of (at least) two actors to handle these responsibilities.

As I say, I started exploring this, realized how much work would be involved in creating this runtime, and then got sidetracked by some other work regardless.

Copyright (c) Marimer LLC