Hi Tony

> I appreciate the continued focus on leveraging tiddlers as the basic store 
> but we need to extend their handling in some ways if we want them to also 
> represent records in the equivalent of database tables. Here I am thinking of 
> hiding the "data record" tiddlers from standard searches without prefixing 
> them with $:/

The way to do that is probably to make a custom search results tab that hides 
the tiddlers you want to ignore/

> and somehow enabling the same key (tiddlername) to be used to address 
> different records in different logical tables/or namespaces (see below).

The title is a unique key. If you want to address tiddlers by a non-unique key 
then you’d use a field.

> To me however allowing the designer to to make use of fully featured "data 
> tiddlers" adds great strength to tiddlywikis ability to respond to all 
> possible data structures someone may wish to represent in tiddlywiki. 
> Enabling JSON to the fullest extent also increases TiddlyWikis ability to 
> interact with external data sources as many sources such as xml can be 
> converted to JSON if not yet available. We do not need to code for all 
> possible data sources if we comprehensively adopt a robust standard like JSON 
> because we can leverage external tools written for the conversion of data 
> between standards and maintained by others.

Are you saying that you’d like TW5 to have better interop with existing JSON 
files and APIs? I think Joshua is exploring the approach of extending the 
existing data tiddler mechanism. In some of my own work I have explored a 
different approach, “exploding” JSON documents into multiple tiddlers, where 
each tiddler represents a node of the document. It’s one of many incomplete 
plugins that I must get around to releasing.

> Joshua's tools are extensive and I hope they may improve such handling in the 
> future.
> 
> Given the maxim that if you place a problem on the table you should place a 
> possible solution there as well;
> If we could introduce additional name spaces which are not in the tiddler 
> name, such that when one of these is set the <<currentNamespace>> can refer 
> to the tiddlers there in with <<currentTiddler>> then a database table could 
> be created in its own namespace, with identical tiddler names to those in 
> other namespaces. A names space can be used as a table name.
I’m not sure I’m following your exact meaning, but it sounds like you want TW5 
to behave more like a database.

> Of course this would be a challenging thing to implement but its benefits 
> would be extensive and would allow further use of tiddlers as the atom of 
> data. Careful design would make the use of additional namespaces invisible 
> until a user/designer starts to use additional ones.
I’m not sure what you mean by namespaces, but some of what you’re describing 
sounds like the plugin mechanism.
> To be able to filter tiddlers in one namespace and use this as a key to 
> tiddlers in another namespace would be needed.
Maybe you’re talking about something like TiddlyWeb’s “bag” model of storage? 
We have considered implementing that model within TW5 itself, whereby the store 
would be a list of independent bags.

> This can be done with prefixes, remove prefix and lookup operator but the 
> logic is far more complex and harder to follow or design. 
Core changes are expensive, even if only in opportunity cost. If something can 
be done without needing core changes then it’s hard to justify prioritising 
those changes, especially if the proposal is in such an early state.

In this particular case, it does sound like prefixes are the way to go. It’s a 
standard technique used endlessly by the core, and of course it’s the natural 
to slice up a single namespace.

Best wishes

Jeremy.



> Regards
> Tony
> 
> On Thursday, July 25, 2019 at 2:49:00 AM UTC+10, Jeremy Ruston wrote:
> Hi Mat
> 
> Some history that may help… data tiddlers were added quite close to the start 
> of TW5. They were part of the work to implement colour palettes; I was 
> concerned about the proliferation of tiddlers if each system colour were to 
> be given its own tiddler.
> 
> https://github.com/Jermolene/TiddlyWiki5/commit/baff9016858133d300a9662ffd1782568454f8eb
>  
> <https://github.com/Jermolene/TiddlyWiki5/commit/baff9016858133d300a9662ffd1782568454f8eb>
> 
> My initial intention was to provide support for generic JSON tiddlers, with 
> syntax to address individual items within such a tiddler. Data tiddlers would 
> have been one of a number of alternative representations for specific 
> schemas. Joshua is now exploring ideas along those lines.
> 
> But my gradual conclusions were that:
> 
> * Adding the “index” mechanism for addressing items within a data tiddler 
> introduced a lot of complexity right across the code base that is still there 
> today
> * Figuring out an addressing mechanism for items within a JSON object would 
> end up re-inventing something as complex as JSONPath
> * Proliferation of tiddlers isn’t actually a problem for performance with the 
> core. The problem is more cognitive; too many random tiddlers and most of our 
> lists become useless. There are lots of ways we can address that issue — for 
> things like palettes I would we might pack the individual tiddlers into a 
> plugin
> 
> We do of course also use JSON as a container format for tiddler files, but 
> that is handled by the import mechanism.
> 
> Best wishes
> 
> Jereym
> 
> 
> 
>> On 23 Jul 2019, at 02:32, Mat <matia...@ <>gmail.com <http://gmail.com/>> 
>> wrote:
>> 
>> What is the point with JSON tiddlers over regular tiddlers? What do they 
>> enable and what limitations are there?
>> 
>> One point that I do get is that other software often has the possibility to 
>> export/import JSON so it could enable data transfer with TW.
>> 
>> There does not seem to be an advantage when it comes to data tiddlers 
>> because the JSON data tiddlers can only be on the JSON root level whereas a 
>> regular tiddler is deeper.
>> 
>> One reason why I'm asking is because I hope to build a UI for Jeds 
>> FederationCore plugin 
>> <https://ooktech.xyz:8443/Public#%24%3A%2Fplugins%2FFederation%2FFederationCore>
>>  that extracts data from the so called tiddler "bundle" which is the format 
>> that fetched tiddlers come in. Bundles can be packed into a special bundle 
>> format or into JSON. 
>> 
>> Thank you!
>> 
>> <:-)
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "TiddlyWikiDev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to tiddly...@ <>googlegroups.com <http://googlegroups.com/>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/tiddlywikidev/c8c24a82-a99e-402b-8b79-e6ff02ff8184%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/tiddlywikidev/c8c24a82-a99e-402b-8b79-e6ff02ff8184%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "TiddlyWikiDev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] 
> <mailto:[email protected]>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/tiddlywikidev/f54ebf05-1eb0-4b9b-ac46-9e8230c196c1%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/tiddlywikidev/f54ebf05-1eb0-4b9b-ac46-9e8230c196c1%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/602CA2F5-9C2B-4390-9774-EB8E5F4B6157%40gmail.com.

Reply via email to