Some Suggestions for Version 5

[a44281071]

Some Suggestions for Version 5

Due to the addition of new GUI platforms and the existing asynchronous support, I have some ideas here that I hope to discuss and confirm.

Regarding Naming

Since this is a new version, we can adjust the naming under permissible conditions, of course, with some principles:

• If there are names that are similar but have different functions, or if the code input characters are too similar to make use of code prompts difficult, it is recommended to modify them.

• If the code that can be easily completed may conflict with the definition or even cause errors, or if the names are not understandable to users, it is recommended to modify them.

• Any modifications must be marked with how to upgrade from V4 to V5, and should be easily accessible in the official documentation.

The following code example meets condition 1.

// means 'before active' or 'Activating'
protected override Task OnActivatingAsync(CancellationToken cancellationToken) { }

// means 'after active' or 'Activated', in Blazor platform, use [OnAfterRender{Async}](https://learn.microsoft.com/en-us/aspnet/core/blazor/components/lifecycle?view=aspnetcore-9.0) 
protected override Task OnAfterActivatedAsync(CancellationToken cancellationToken) { }


protected override Task OnInitializingAsync(CancellationToken cancellationToken) { }
protected override Task OnAfterInitializedAsync(CancellationToken cancellationToken) { }

The following illustrates the naming issue of cal:View.Context.

MyNamespace.Views.StudentViewModel. locate to: MyNamespace.Views.StudentView.
locate with context (Details): MyNamespace.Views.Student.Details.

A question that was raised a long time ago: It pollutes the name definition.
I must define a namespace like xxx.Student.xxx. But I also have a model named xxx.Student.cs. It's weird to reference members. Student is a class, and also is a namespace.

The following illustrates the issue of conflicting with common types, but it may also be difficult to improve the current situation.

Caliburn.Micro.Action often conflicts with the existing System.Action, but it is generally only used in views, and its namespace can be modified to prevent it from using the same namespace as common types.

Caliburn.Micro.Screen may also often cause trouble with System.Windows.Forms.Screen and Avalonia.Platform.Screen, but this class is very commonly used, while the platform-specific classes like forms and avalonia are less commonly used, so the necessity for modification is lower.

Support for Asynchrony

• If asynchrony is supported, can synchrony also be retained?
• Asynchrony introduces delayed results, making the addition of states quite necessary.

The following demonstrates that if we have asynchronous methods, we can also retain the old synchronous methods, which might prevent the writing of some strange code.
However, this could also potentially lead to the mistake of writing void task.

// In the implementation of the Blazor platform, the old synchronous method is executed first, followed by the new asynchronous method.
// class MyScreen : Screen
protected override void OnActivated() 
{  
}

protected override Task OnActivatedAsync(CancellationToken cancellationToken)
{
    return base.OnActivatedAsync(cancellationToken);
}

The following demonstrates that if we use a synchronous approach to execute asynchronous methods, we should add more states, rather than just a boolean value, to prevent strange results:

// Have 3 active states: [Ready | Activating | Activated].
// Maybe have deactive states? [Deactivating | Deactivated].
public ScreenStatus ActiveStatus { get; private set; }

public bool IsActivated => ActiveStatus == ScreenStatus.Activated;

[GuiThread]
protected override async Task OnActivateAsync(CancellationToken cancellationToken)
{
    if (ActiveStatus == ScreenStatus.Ready)  // Ensure item.
    {
        ActiveStatus = ScreenStatus.Activating;
        await ActiveChildItemAsync(cancellationToken);
        ActiveStatus = ScreenStatus.Activated;
    }
    else if (ActiveStatus == ScreenStatus.Activating)
    {
        // Ignore Activating, it is busy activating asynchronously. (Or cancel if a different child item is needed?)
    }
    else if (ActiveStatus == ScreenStatus.Activated)
    {
        // Ignore Activated, it is already finished.
    }
}

[vb2ae]

Thank you for your feedback.

• I do like the idea of adding some of the synchronous methods back.
• I do agree the async methods naming can be improved.
• I don't think that renaming Screen or Action is easy to change. Would have to support 2 names for screen and Action for a few releases. We would have to add a Roslyn analyzer that adds a warning saying Screen is being renamed.
• I have a couple of ideas about changing how we match a view with a ViewModel.
  • First we could make some of the properties in ViewLocator and ViewModelLocator used for matching more accessible in the bootstrapper.
  • I am also thinking about adding an attribute to the Screen [ViewModelFor("MyProject.Views.MyAmazingView.xaml")] to make easier to match views and viewmodels that dont match the pattern exactly

[a44281071]

Yes, I have also worked on adding attributes|interface to VMs (ViewModels) to make the subclass match the parent class's V (View), or to make a single V match multiple VMs. However, the latter scenario is relatively rare. There are also mechanisms similar to "FallBack" for handling such cases.
Regarding Caliburn.Micro.Action, it is commonly used in the view layer, so we can leverage XAML aliases to achieve zero modifications in XAML while hiding this type in the code, using XmlnsDefinition and XmlnsPrefix.
As for 'Caliburn.Micro.Screen', it is indeed quite difficult to modify because it is used so frequently.
Additionally, I have some thoughts on Bootstrap. New project templates now commonly use the Host approach for configuration and startup, such as the .NET Generic Host
. This has influenced the entry code of many frameworks like ASP.NET, MAUI, and Avalonia. It also makes it easier to override or modify default conventions. Perhaps we can have a good discussion about this, and maybe even replace IoC more conveniently.
For example, when it comes to IoC, many people might prefer .NET dependency injection
or Autofac, because more projects are now inclined to support Microsoft.Extensions, which makes it easier to integrate with the community.
Regarding code generation, I often use Fody because it is more straightforward in some cases and does not have the invasiveness associated with base classes or the need for 'public partial class'. However, in some cases, 'CommunityToolkit.Mvvm' does seem to have a brighter future. It will take some effort for our CM framework to support it.