-
Notifications
You must be signed in to change notification settings - Fork 50
Short XAML syntax on Short XML syntax #73
Comments
I thinks the main goal of an interface is to ask people implement it. XAML standart is like a big interface in code. If you start to change the base some project will not accept the load to implement or will lose time to implement it. WPF and uwp are not the only one in the dev ecosystem. Such change need to come from a big interest. If you want somethinks like that you may make a tools like "ammyui" compile into XAML. |
Thank you your comment. I know this project is XAML library project. but, I think about short XML syntax when I think about XAML. |
I found RELAX NG Compact Syntax https://en.wikipedia.org/wiki/Simple_Outline_XML SOX is like YAML. |
I think the advantage of HTML over XHTML is the possibility of omission. |
if your intent is to do less typing, then why not just use something like HJSON? XAML: <-- this is my button -->
<Button x:Name="MyButton"
Content="My Button"
Click="MyButton_Click"
Command="{Binding MyButtonCommand}" /> HJSON:
|
ahem, XAML looks much better, esp if some shorthand binding mechanism was added |
The only thinks i talk about is a way to implement what ask without using Xaml-standart. By using à compiler that compile into Xaml or baml. It will be more efficient and free to add language specific feature. |
could fork AmmyUI if it's code is available btw, here is a XAML to Ammy converter, could change it to make your-own-XML to Ammy one note that AmmyUI has support for WPF/Xamarin.Forms/UWP/NoesisGUI targets already |
XAML and JSON is a bad idea, as the nature of XAML is quite verbose and implication that tooling partners would have to factor in duck typing over structured XML is a deterrence. If you then infer that JSON follow a set naming convention then its really not a JSON moment and more of a JSD? which again means you have to backfill it with the vocabulary around its implementation which negates the idea of what XAML is. |
JSON is a terrible format for configuration; that is not its intent. However, there are qualities about it that are admirable and that is what people are drawn to here with Ammy. There is certainly a difference between describing objects and the format they are described/stored in. Hey @gulshan I keep thinking your ideas/efforts with dotnet/roslyn#16648 could possibly tie in well with this new Xaml Standard. Tagging you here so you are aware and can participate accordingly, if you aren't already. :) |
btw, I don't like the idea of a C# notation format instead of a languaage agnostic one for .NET but being able to convert XAML to an imperative format that constructs a UI graph can help in cases like this (where WPF/UWP fall short compared to Silverlight): #100 (unless they decide to fix the issue they could use this conversion to compile/inline XAML used in ancestor UserControls as a workarround) |
@birbilis I believe the idea is to have it as a certain format by default (I myself am partial to XML, even though it is technically a "language"), but being able to align it to any format as long as there is a provider. At least, that is how it should be. I would also caution the use of this for exclusively UI-graphs. That is how things like UWP happen. 😉 This can be used to create any POCO, really. Which was the fundamental power and appeal of Xaml from the start. |
Xaml should stick to its current, any other format should be a third party implementation. Xaml should and must be aimed for more than technical people, actually technical people should in the end be more assisting. When you remove them from the picture we might as well throw XAML standard and any implementation away. |
100%, @Duranom! The value in a code-agnostic, designer-friendly format is that it is ultimately cheaper to develop, manage, and maintain from a resource management perspective. If I run a business and I have to hire/aquire a C# developer/resource to maintain a deployed application, vs. one that requires someone who simply knows XML/JSON, we're looking at the difference between $50-$75 per hour to do so. Even greater if the XML/JSON is tied to a pretty designer surface that does most of the work for the resource having to work with it. This was the promise of Xaml, in that it facilitated and assisted in the tedious and expensive workflow process between developer and designer. However, there is conceptually nothing stopping this same principle in being applied beyond this (e.g. DevOps workflow as alluded to above). |
XML is wonderful, however, there is room for improvement.
SGML used in HTML is complicated.
I think Extended XML (XXML).
XXML is very simple XML like language.
But, XXML has the schema as shown in Fig 1 and Fig 2.
XXML implementation writing Scala language is here.
If you don't mind, please consider XXML support for XAML Standard.
thanks, h_sakurai.
Fig 1. XXML Schema example
Fig 2. Using XXML Schema example
The text was updated successfully, but these errors were encountered: