I was using that to set the stage for the discussion in what I thought would be a much longer post. But it was late at night, and I dozed off several times trying to write it. I gave up and dropped much of what I was going to discuss. I just wanted to be clear that when I used “relationship”, I didn’t mean specifically romantic or sexual ones. If I’d been less drowsy, I would have removed that intro before posting it.
That said, it would certainly be possible to write such handling code for an underlying object model.
Pros
-
The current structure very much favors flat data structures. It can become awkward to model situations that would be best handled by nesting. JSON shines there.
-
It could be really useful for more robust importing and exporting, making it easier for TiddlyWiki apps to interact with external systems, many of which operate using JSON.
Cons
-
Everything is a tiddler[<person>get[address]get[city]], because the address is itself a tiddler. If deep JSON storage became common, we would be dealing with two parallel data stores, with, I contend, little additional value. I’m not going to dig up the reference right now, but I’m quite sure that @jeremyruston has publicly regretted the introduction of data tiddlers. I’m guessing it’s for similar reasons. -
[tag[Filter Operators]]returns 174 operators. At a rough guess, we would have to handle half of them for JSON, either replicating or expanding them to handle plain objects as well as tiddler titles. This is a lot of work. -
JSON is a string format, meant for storing or transferring in-memory objects. It is not itself a real data format, and any serious work with it will entail converting input JSON strings into actual objects, manipulating those objects, and converting them back to JSON strings for storage. This is a likely a performance drain.
-
We already have an in-memory Object store. In a very important sense, that’s what TiddlyWiki is. Adding additional ones just complicates things.
You might want to look again at @tomzheng’s SSSPC work. That is discussing a similar idea, in a more abstract manner. I found it difficult to understand, and I created a summary of if in another thread. While I don’t see any use for that approach in my work, it’s definitely interesting in its own right.
My concern with putting the data into the title is the combinatorial one: It’s fine with any parent-child relationship (literal or figural) but gets stickier when it’s spouses: who do you put first? Even if we were restricted to traditional wife-husband pairings, that choice seems difficult, and when you move beyond that, it feels impossible, so you will probably end up with something arbitrary, such as alphabetic or by numeric id. And then searching can become awkward. If you move to relationships among three entities, it gets worse, because there are six orders they could come in. And it gets progressively worse.
That’s exactly how TW works. However, the methods that get called are usually not the primitive methods, but things that have been built atop those primitives for use in TW. We would need a similar layer for working with JS Objects.
It’s already there. The format Operator has a json suffix, and if you pass it a number, the output will be indented that number of spaces. And if you pass another string, it will be used literally as the indentation:
<$let data='{"foo": 1, "bar": {"baz": true, "qux": "abc"}}'>
<pre><$text text={{{ [<data>format:json[4]] }}} /></pre>
<pre><$text text={{{ [<data>format:json[...]] }}} /></pre>
</$let>
yields:
{
"foo": 1,
"bar": {
"baz": true,
"qux": "abc"
}
}
{
..."foo": 1,
..."bar": {
......"baz": true,
......"qux": "abc"
...}
}