Replies: 6 comments 2 replies
-
Maui XAML processor and compiler are open-source |
Beta Was this translation helpful? Give feedback.
-
|
Cross posted comment from WinUI repo I wonder if it'd be easier to add-on/follow the conditional XAML approach that was taken for windows versioning? e.g. <Page xmlns:debug="http://schemas.microsoft.com/winfx/2006/xaml/presentation?IsDirectivePresent(DEBUG)"
xmlns:release="http://schemas.microsoft.com/winfx/2006/xaml/presentation?IsDirectivePresent(RELEASE)">
<StackPanel>
<debug:TextBlock Text="This only shows up in Debug Mode"/>
<TextBlock Text="This will be bold in Debug Mode" debug:FontWeight="Bold"/>
<release:Image Source="..."/> <!-- This image only shows up in release mode -->This would feel familiar to existing patterns for developers and also allow a bit more fine-tuned control over specific properties vs. large chunks with regions. You also get immediate context with each element when it is used with which directive it will be attached to vs. having to know it's in a special comment block. |
Beta Was this translation helpful? Give feedback.
-
|
The idea of having conditionals in XAML isn't new. The main problem with those is that it might create invalid xml or invalid xaml when the conditional instruction/comments are ignored. This proposal is more resistant than some, as it uses start and end instructions, but isn't 100% bullet proof either: <Grid>
<!-- if ... -->
<Label />
</Grid>
<!-- else ... -->
</Grid>
<!-- endif -->Should this be allowed, frowned upon, or rejected by the parser ? |
Beta Was this translation helpful? Give feedback.
-
|
instead of abusing comments, this proposal should use xml processing instructions instead <?xaml-cond if $(DEBUG) ?>
<Label ... />
<?xaml-cond endif ?>to allow the reuse of existing tools for xml processing |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
@michael-hawker proposal always produces valid xaml, which is a |
Beta Was this translation helpful? Give feedback.
-
|
That would a pretty important feature for me, and for anyone providing Xamarin.Forms components... |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I just run into this and want to use the same XAML in XF and MAUI, but now stuck with different namespaces in xaml 🤔 |
Beta Was this translation helpful? Give feedback.
-
Compiler preprocessor directives are a powerful tool when working with many programming languages, but they are not available for use in XAML files. Adding them could greatly increase the flexibility of what is created in XAML, reduce code duplication, and allow logic to be better contained in a single XAML file rather than require logic to be split between the XAML file and its accompanying code-behind file.
Rationale
.xamlfile and its accompanying code-behind file (e.g..xaml.cs)Note. I recognize this is a tooling request and not related to parts of .NET MAUI that are (or will ever be) open-source and so I'm happy for this to be redirected as appropriate. Alternatively, I will repost elsewhere if you can point me to the appropriate place.
Such as can be done in other languages, instruction is provided in the code to indicate which parts of the file to include during compilation.
This proposal is to directly mirror the options available in C# but contain them inside XML(XAML) comment blocks and use a slight modification--explained in more detail below.
Example:
Assuming the above was in the user authored file, and then the code was compiled with the
DEBUGdirective specified, the version of the XAML that was passed to the compiler (language service) and include in the assembly would be:The comments and anything not appropriate to include based on the available directives should be invisible to the rest of the compilation process and compiled application.
I suggest putting the directives inside comment blocks, so they are ignored by any other tooling that looks at XAML files but doesn't know about this capability. Adding something entirely new could risk breaking lots of other things...
Individual directives are indicated by specifying them between
$(and)to reflect the notation used in msbuild files.The definition (or setting) of directives within a XAML file must also be supported. This should be in a similar manner to that explained above.
example:
The use of
$(and)in the definition is to avoid any possible confusion about the inclusion of whitespace and the closing comment characters (-->).One or more whitespace characters should come after
<!--characters and before the directive.One or more whitespace characters should come after the directive and before the closing
-->characters.Directives in comments should always be in a single line and not be supported in comment blocks that go over multiple lines.
Directives specified at the project level (inside
.*projfiles) should be available within all the XAML files inside that project. It should not be necessary to re-specify these in the XAML field where used.Appropriate coloring and autocomplete options should also be provided.
Open Questions
#ifor#elifblock to check for more than one directive at a time? (If it is this would presumably be done by using|between directives to indicate OR and&between directives to indicate AND. If supported how advanced should this logic be and would it need additional brackets to manage precedence?)<!--and before-->?Justification / Intended Use-Case
The aim of this proposal is to reduce complexity when working with XAML files in more advanced scenarios.
Specifically, it aims to reduce the need to have to put logic in a code-behind file when doing everything in XAML would be preferable.
I often make apps that need to include pieces of UI that should only be available in DEBUG, QA, or other special builds.
When the logic for controlling the displaying or hiding of elements is split across the XAML and code-behind files, such functionality is frequently broken when the files are being worked on by multiple people. When just looking at the XAML file it is not immediately clear that there is accompanying logic related to it in the code-behind file. If all the logic is in one place it would be much more obvious and make code maintenance easier.
We've tried alternative approaches to this, but they have each ended adding more complexity to the codebase when all we want is something that is available by default in other languages.
I'd also like to see this change made as, I believe, it is relatively simple and would demonstrate to the wider development community that you to still intend to support and invest in XAML as a platform for defining application UI.
Beta Was this translation helpful? Give feedback.
All reactions