Open egvijayanand opened 2 years ago
Type resolution won't be an issue in case of a type name clash, as the alias names will still be in the same namespace defined with the xmlns prefix (root namespace, without any xmlns prefix in case of .NET MAUI controls), whereas user-defined types with the similar type name will be given in a different xmlns prefix.
namespace MyApp.Views;
public class HStack : HorizontalStackLayout { }
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui" xmlns:v="clr-namespace:MyApp.Views">
<Grid RowDefinitions="Auto, Auto">
<HStack Grid.Row="0">
<!-- .NET MAUI Control with proposed Alias configured -->
</HStack>
<v:HStack Grid.Row="1">
<!-- Control from the specified namespace, user defined -->
</v:HStack>
</Grid>
</ContentPage>
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
Description
Suggesting to introduce a new attribute, like XamlAlias, so that long view names can be referenced with its Alias.
For example,
HorizontalStackLayout
can be shortened toHStack
and used within the XAML code.The attributes need to be defined on the definition of intended types. This is similar to the
ContentProperty
attribute, where mentioning the default content node is optional likeContentPage.Content
.Though it is possible to sub-class the type with the shortened name and use it, the issue will be the style definitions needs to be allowed to extend for derived classes and that can have consequences if other real definitions are available within the project.
During Xaml compilation, the alias names are to be replaced with actual type names.
This will simplify things and improve productivity.
Public API Changes
Intended Use-Case
Before:
After: