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…
When XML Beats JSON: UI Layouts
211–220 of 274 posts
Re: When XML Beats JSON: UI Layouts
#212Re: When XML Beats JSON: UI Layouts
#213Earlier quoted context omitted.
You should have read the next paragraph. They do use that as an example Michael Scott Diehard Threat Level Midnight
Fair! Why the heck did the author first try to tell us XML had no "officially supported way" to do this then?
Re: When XML Beats JSON: UI Layouts
#214Instead of hard coding your hierarchy into the structure of XML or JSON. Define some basic type information (unique id and node type).
If you have situations where an object can be referenced before it is defined simply make a proxy loading type that listens for it to load.
After that it is a cakewalk:
[
{
id: "UUID OR Rolling Number Per File OR DB Index OR ...",
type: "business",
name: "Dunder Mifflin Paper Company, Inc."
description: "look at me I can be a root type for the graph OR one of many!"
offices: [
list of ids of objects of type "office" or object that wraps this with other metadata (relation object)
]
},
... potentially other business entries,
{
id: see above...
type: "office",
name: "Scranton Branch",
description: "This can describe each branch"
departments: [
list of ids of objects of type "department" or object that wraps this with other metadata
]
},
... other offices,
{
id: see above...,
type: "department",
name: "sales",
members: [
list of ids of objects of type "employee" or object that wraps this with other metadata
]
},
... other departments,
{
id: see above...,
type: "employee",
title: "manager",
name: "Michael Scott",
reports: [
list of ids of objects of type "employee" or object that wraps this with other metadata
]
},
{
id: see above...,
type: "employee",
title: "sales man",
name: "Dwight Schrute",
reports: [
id of self since Dwight needs someone he can trust,
{
id: see above...,
type: "report_meta",
reportee: id of Pam,
visibility: "secret"
}
]
},
... other employees,
etc.,
etc.
]Re: When XML Beats JSON: UI Layouts
#215I've seen a lot of XML vs. JSON discussion that misses the point why developers like me love JSON so much, at least until things get really big, or you want to add another 9 to your reliability [1]. JSON is so easy to get started with. Some of this is precisely because of the lack of schema. In Java with the GSON library, encoding/decoding is one function call and for the things I've been doing this just works at lea…
Re: When XML Beats JSON: UI Layouts
#216Earlier quoted context omitted.
> The simplicity of JSON is an advantage: it prevents people from mucking it up with too much nonsense like this. JSONs simplicity was out the window before it became a formal spec. The original designer of JSON omitted comments from the final spec because people were using them to create processing directives. There are multiple differing implementations of JSON parsers, the most notable differences between them bei…
>EDIT: Oh, and instead of CDATA, we now simply base64 encode arbitrary objects and pack them into JSON encoded strings. Is this really an improvement? I think that's more of an indictment of HTTP than XML or JSON. Maybe we should have a better standard for exchanging non-textual data with websites.
Re: When XML Beats JSON: UI Layouts
#217At 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…
- Editing XML is actually a lot easier than JSON. Thanks to XML schemas, completion works really well in XML and very poorly (if at all) in JSON.
- Also, XML allows comments, which JSON doesn't.
- You don't need `findViewById()` in 2019 and haven't in a while, really: there are plenty of alternatives available (synthetic accessors, Kotlin, ButterKnife, etc...).
Re: When XML Beats JSON: UI Layouts
#218Interesting to see the history here: XML was created and solved a lot of problems. So on the bandwagon everybody jumps. Then it became bloated and fragmented, so the world switches mostly to JSON. But on the XML side, the baby was thrown out with the bath water, while JSON started developing its own abuses. TOML and YAML come in and muddy the waters a bit more. This is only 1 article, but maybe the world is ready to…
The moment we added JSON schema (not to mention JSON transforms) and started to create a JSON version of XPath, we started down the same path that hurt XML. Throw in parsers that all act differently (some parse comments, some don’t), and processing directives, and it becomes clear that yes, the pendulum has swung too far.
There is an amazing JSON schema syntax out there, 100% better than the official one. It is called TypeScript, and I am sad that the TS compiler can't be made to pop out JSON validators (their philosophy being nothing at all runtime).
There is a project (I forget its name) that will insert itself into your build steps and use TS type definitions to validate JSON.
Seriously the TS syntax is great, why is anything else being used to write a schema?
The only thing I'd add to the TS syntax is the proposals to add field validation using regexs, or some type of field name validation format. There are times when TS can't model my JS objects, e.g. I have a bunch of GUID field names that map to objects of a certain type, and I have some other field names that are 100% not GUIDs, I promise, mapping to some other stuff.
Re: When XML Beats JSON: UI Layouts
#219Earlier quoted context omitted.
TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.
I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)
YAML is all sorts of strange.
JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!
Re: When XML Beats JSON: UI Layouts
#220> 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"} (…
1 1 0 1
0 1 1 0
>It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm
It is not concise. Here is an example of a single div tag overhead:
["div",{"class":"some classes"}, ... ]
...
Also, it does not represent DOM trees as JSON. It represents DOM trees as S-Exressions encoded via JSON. The s-expression above can be written directly as:(div (class= "some classes") ... )
So why does it need to be wrapped in a format that's verbose, underspecified, doesn't have comments, doesn't have namespaces and doesn't have any notion of metadata?