Print Page | Close Window

Cocktail 2012 Compatibility assembly

Printed From: IdeaBlade
Category: Cocktail
Forum Name: Community Forum
Forum Discription: A professional application framework using Caliburn.Micro and DevForce
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=3650
Printed Date: 21-Aug-2025 at 5:06pm


Topic: Cocktail 2012 Compatibility assembly
Posted By: Walid
Subject: Cocktail 2012 Compatibility assembly
Date Posted: 22-Sep-2012 at 2:53pm
Hi,

I notice not all the previous result type are in the Compat package. I am talking about DialogOperationResult and NavigateOperationResult, why adding others but not those two ?

I know there is a new Navigate service but since you kept the signature method I expected to keep the OperationResult.


Replies:
Posted By: mgood
Date Posted: 22-Sep-2012 at 11:00pm
I didn't see much value in adding DialogOoperationResult. The only difference really is that you now need to use the Result property instead of DialogResult. The Compat package already requires minor code changes and this falls in that minor category in my opinion.
As for NavigateResult, Navigator works fundamentally different then the previous NavigationService. With the NavigationService you navigate to an instance of a ViewModel. With the Navigator you navigate to a type and it creates the instance for you. The signatures are not compatible as such, but I added a signature returning OperationResult to the Compat package, so that you can at least use Navigator in an existing coroutine without having to explicitly convert the returned Task, even though the rest of the signature can't really be made compatible.
 
What specific issues is it creating for you?

Posted By: Walid
Date Posted: 23-Sep-2012 at 10:01am
Ok, I wasn't sure how to access the selected button. So, using OperationResult, this is the way to do it ? (The whole solution doesn't compile yet so I can't test it)

OperationResult<DialogResult> op;
yield return (op = DialogManager.ShowDialogAsync(...));
if (op.Result = DialogResult.No)
...

I don't want to use async/await yet, first I want a working migration without changing too much code, the migration to Task will come next.


I also noticed you changed the signature of all the methods previously returning IResult. Does that mean Caluburn micro is also compatible to Task so I can get rid of all IResult reference into the application ?

Posted By: Walid
Date Posted: 23-Sep-2012 at 10:32am
It looks like each call to NavigateToAsync create a new instance of the target Viemodel while in the previous implementation we were able to provide the instance to the service.

I implemented a Wizard service based on the old Navigate Service, so I need to be able to go back on existing instance.
How is that possible with the new service without exporting as Shared the Viewmodel ?

Posted By: mgood
Date Posted: 23-Sep-2012 at 11:43am
Originally posted by Walid

Ok, I wasn't sure how to access the selected button. So, using OperationResult, this is the way to do it ? (The whole solution doesn't compile yet so I can't test it)

OperationResult<DialogResult> op;
yield return (op = DialogManager.ShowDialogAsync(...));
if (op.Result = DialogResult.No)
...

I don't want to use async/await yet, first I want a working migration without changing too much code, the migration to Task will come next.


I also noticed you changed the signature of all the methods previously returning IResult. Does that mean Caluburn micro is also compatible to Task so I can get rid of all IResult reference into the application ?

Yes, you use the returned OperationResult to access the selected button.

Yes, instead of using IResult you turn actions etc. into async methods. See TempHire.

Posted By: mgood
Date Posted: 23-Sep-2012 at 12:01pm
Originally posted by Walid

It looks like each call to NavigateToAsync create a new instance of the target Viemodel while in the previous implementation we were able to provide the instance to the service.

I implemented a Wizard service based on the old Navigate Service, so I need to be able to go back on existing instance.
How is that possible with the new service without exporting as Shared the Viewmodel ?

NavigateToAsync creates instances based on the export part creation policy. If you export as NonShared, then it creates a new instance, otherwise with Any or Shared it will reuse the same instance.

You shouldn't need to share VM instances for a wizard, though. The wizard should be backed by a unit of work that tracks all the changes and data. You pass the unit of work from page to page and each page knows which part of the data in the unit of work it operates on, so if you go back to a previous page the new VM instance can initialize itself from the unit of work in order to show the correct information. 

Posted By: Walid
Date Posted: 23-Sep-2012 at 12:17pm
That's the case, I already have a UOW for the wizard. My concern was more about having a fluid navigation.
If I have to recreate a new instance of the View/ViewModel and load the data (from cache), I can see the busyindicator working and I would like to avoid that (even if it's only during less than half a second).

Anyway I will do like you suggest and will see how it's going.

Thanks

Posted By: mgood
Date Posted: 23-Sep-2012 at 12:57pm
You shouldn't see the busy indicator. All cache queries are synchronous. The UI thread is never free to display the busy indicator, by the time it's free, the busy property on your VM will be false. If you look at TempHire, you don't see the busy indicator if you select a staffing resource that is already in the cache, even though it creates a new detail VM.

Posted By: Walid
Date Posted: 24-Sep-2012 at 3:59am
I have one case where the new NavigateToAsync method doesn't fit my scenario.

I have a module allowing me to create/edit multiple Company at once.
A Conductor (OnActive) allow me to keep trace of all CompanyVM instance and a listbox (bind to Items property) allow me to select the one I want to show in the ActiveItem control

before I could just have a method like :

public void ShowCompany(CompanyVM company)
{
    NavigatorService.NavigateToAsync(() => company);
}

Now with the new service, what is the best way to have the same behavior ?

When I will call ShowCompany this will create a new instance which will appear in my listbox (the old one will still be there). So I will have to manually remove the "old" instance which looks a bit ugly to me.

Any though ?

Posted By: mgood
Date Posted: 24-Sep-2012 at 4:22am

Navigation in the traditional sense means that you close the current view and open a different view, so you need to do things like checking if the current view can be closed in it's current state.

In your scenario you toggle between multiple open companies, that's not navigation. The current active VM doesn't get closed when you toggle to another company. It simply gets deactivated, so the Navigator is overkill and misplaced here. It's enough to just call ActivateItem(company).
 
This scenario is very much like the tabs on the detail VM in TempHire.

Posted By: Walid
Date Posted: 24-Sep-2012 at 7:51am
Ok sound logical.

thanks


Print Page | Close Window