Screens Example

Feb 22, 2011 at 4:31 PM

I was looking at the screens sample and I have a question about a variation of this.  The way it is currently structured there is an areas of the application based on a given workspace and it has a master and a detail view for each. 

This is fine in most cases, but the guidance or suggestions I am looking for is how to best handle a workspace that is responsible for managing say all lookup tables or configuration data for a given application.  This means that the button on the bottom for this said admin area would not have just one type of screen to manage; hence needing more than just a master and a detail view.  In this case it would need one master and many detail views based on the number of different admin areas of the application it needs to  manage.  To expand on this the master view would have buttons or sub navigation to access numerous different screens and also would have a list of the open screens in the workspace.  But in clicking or navigating to the other screens it would load new screens and not the detail screen like it current implementation would.

Any tips or suggestions would be greatly appreciated.

Feb 23, 2011 at 4:24 PM

Wow, No ideas here?

Is creating a new abstract workspace type for just the admin area with different states other than Master and Detail seem like a reasonable path to take?

Coordinator
Feb 23, 2011 at 4:42 PM

You can basically build it exactly like the CustomersWorkspace. Just add more view models and views. The Master refers to the whether the workspace itself is showing the summary screen or the view of one particular record (Detail). There's nothing to stop you from having different types of view models conducted by the same conductor. When in Detail mode, the framework would just bind in the correct view for whichever specific VM is active at the time. Though, I'm not confident that I understand your exact scenario.

Feb 23, 2011 at 6:05 PM

The current customer implementation shows within that workspace it needs to be of type

DocumentWorkspace<CustomerViewModel>
Say I want to have a CustomerViewModel and CustomerViewModel2 but I want them to live within the same workspace so that on the Master summary screen I see:
Customer 1  -- this one is of type customerviewmodel
Customer 2  -- this one is of type customerviewmodel2
but each one is a different detail view/viewmodel.
How would this be best approached?
I am fairly new to caliburn.micro.
Coordinator
Feb 23, 2011 at 7:16 PM

DocumentWorkspace<object>

or if there is some commonality

DocumentWorkspace<IMyViewModelAbstraction>

Feb 23, 2011 at 7:25 PM

Thanks...I am still trying to wrap my head around all this and wanted to make sure I am not doing something completely wrong.

 

This framework is great, and I appreciate all your effort you put into it.