241–250 of 274 posts
> JSON for lists, XML for trees No. JSON is a recursive data structure that can represent trees as well. It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm I find it really sad that people don't know or consider s-expressions to represent trees. (Department {:name "Scranton Branch"} (Employee {:name "Michael Scott" :title "Regional Manager"} (Department {:name "Sales"} (…
At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake. - For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. - It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to…
What UI framework using XML is there where you can end up making silly typos that won't be caught at compile time? Or basically any sort of typo? I would expect any decent XML UI framework is going to have some sort of validation schema defined which will be quite stringent as to what is allowed at a particular level. Not that I like XML Schema.
Earlier quoted context omitted.
There's no reason this can't be done with code as well. See: SwiftUI
System.Windows.Forms works in the same way (the UI is serialized to code). WPF was designed many years after that because it allows different disciplines to work together. Designers would most likely be familiar with XML given their HTML background, but they wouldn't necessarily know C#. If Swift UI expresses the full fidelity of the API in the designer (e.g. expressing custom states and animations, keyframes, etc. o…
I am really curious how often XAML has been used by a designer who didn't know C#. Most of the XAML I've seen (in non-trivial apps) has a lot of code-like constructs in it. If you don't know what's going on under the hood, how are going to correctly declare your data bindings (for example)?
At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake. - For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. - It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to…
Sorry, but ... ... is more verbose than new OrderedList( new List { new ListItem(...), ... } ); ??
ol(
li(...),
li(...)
)
But honestly, does it really matter? Either choice isn't terrible at all.
> HXML does not use CSS.
I wonder why? XML is perfectly stylable with CSS. Why not let the user reuse their knowledge?
Somewhat canoncial: https://www.w3.org/Style/styling-XML.en.html
Earlier quoted context omitted.
" The only real strengths of XML are that 1) it's declarative, 2) it's hierarchical, and 3) it's diffable. But code can be too, without all of these other drawbacks. " Code generally isn't declarative or hierarchical unless your language is those things as well. A declaratively defined interface in C# would end up being some like a bunch of strings or enums passed to some object constructors. At that point I'd rather…
> Code generally isn't declarative or hierarchical unless your language is those things as well. A declaratively defined interface in C# would end up being some like a bunch of strings or enums passed to some object constructors. At that point I'd rather a an XML implementation that can be verified and processed with tools. I should clarify and say code can be declarative with the correct language support . I agree t…
Ok, but which language do you think would work? Lisp? I like the things you can do with macros and s-expressions as much as the next guy, but you're still left with the question of what should people using C# (which has neither of those things) use to make GUIs.
"1. Triggers, DataTriggers, EventTriggers, MultiTriggers, etc. Here we're dealing with the fact that XML is not a programming language and lacks basic control structures, so we've gone ahead and defined our own mini-programming language just so conditional values can be expressed in XML. Why?"
Correct, all the different sorts of trigger are verbose. But, to answer your question as to 'why?' the reason is because we need a deterministic way to express conditional formatting. If we attempted to accomplish the same tasks with hooks we'd have the problem of intermixing imperative, state-full, code with logic that is supposed to be more deterministic. I've written code like that for WinForms like that and it's ugly and hard to debug.
If you were to try to implement triggers with code behind C#, it would still be very verbose because you wouldn't be writing actual C# logic. You'd be doing something like declaring an object with trigger conditions and results and it would be at least as verbose as the XAML triggers, that is, if you wanted to accomplish the same thing with the same guarantees as with XAML triggers. The problem here isn't really the XML, but the fact that there isn't really an available language that solves the relevant problem. It's not like you could use an `if` statement.
"Ever make a typo in a binding?"
I have. I've also made typos when writing viewmodel objects that implement the `INotifyPropertyChanged` interface to similar effect.
Earlier quoted context omitted.
Sorry, but ... ... is more verbose than new OrderedList( new List { new ListItem(...), ... } ); ??
Well really that could very easily become: ol( li(...), li(...) ) Depending on framework. But honestly, does it really matter? Either choice isn't terrible at all.
Earlier quoted context omitted.
> Code generally isn't declarative or hierarchical unless your language is those things as well. A declaratively defined interface in C# would end up being some like a bunch of strings or enums passed to some object constructors. At that point I'd rather a an XML implementation that can be verified and processed with tools. I should clarify and say code can be declarative with the correct language support . I agree t…
" I should clarify and say code can be declarative with the correct language support. I agree that it's probably not well suited to C# in its current state. " Ok, but which language do you think would work? Lisp? I like the things you can do with macros and s-expressions as much as the next guy, but you're still left with the question of what should people using C# (which has neither of those things) use to make GUIs…
My underlying point is with platforms like iOS and Android adopting declarative UIs, combined with languages like Swift and Kotlin evolving in parallel to better support them, I think we will eventually be able to move on from being stuck with XML.
Earlier quoted context omitted.
"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job. For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.
> For example, XAML does an excellent job in declaring your UI. JSX does a better job. I hate XAML, it doesn't add anything except verbosity over just using C#. The original goal of XAML was to allow bindings to multiple programming languages and to allow designers to use a suite of amazing tools to finished designs off to developers for implementation. What ends up happening is developers write XAML, then they write…
Earlier quoted context omitted.
> For example, XAML does an excellent job in declaring your UI. JSX does a better job. I hate XAML, it doesn't add anything except verbosity over just using C#. The original goal of XAML was to allow bindings to multiple programming languages and to allow designers to use a suite of amazing tools to finished designs off to developers for implementation. What ends up happening is developers write XAML, then they write…
Interesting, I'll have to take a second look at JSX. So far I feel like in certain cases XML is better at declaring objects and their properties (along with their Types). XAML can declare any type and configure it as needed, it is a way of declaring components in a logical fashion. I wonder if JSX/alternatives are a true superset of XML-derived formats. FYI, XAML generates a binary format at compile-time. From my man…
XAML is a lot like Python object constructor syntax with all named parameters except one positional parameter that is a list of child objects (obviously, explicit closing tags rather than a closing square bracket and paren is a difference, but structurally it's m almost identical.) It's certainly a convenience for declaring certain kinds of object trees, especially if your main programming language doesn't have a similarly succinct object construction syntax. JSX is effectively a way of adding an equivalent object constructions syntax to the host (JS) language, rather than requiring it to be in separate code files.