Josua, I thank you very much, on your formulas announcement.
*On JSON *recently came up with a method to allow the user to bypass a json tiddler containing tiddlers, of a set of files dropped on the wiki, and save it as a single JSON tiddler. Then on opening the json tiddler you can extract the tiddlers as desired, perhaps to overwrite one you were experimenting with. Let me know if you want more details. I have a little barrier that the tm-perform-import message always wants to replace the json with an import report. I could work around this but as discussed above perhaps there is a way that can improve hackability and solve this. Regards Tony On Friday, July 26, 2019 at 1:18:56 PM UTC+10, Joshua Fontany wrote: > > It took me a while, but I patched up Evan's Modloader plugin to work with > 5.1.20-pre, so I can patch in the handful of function calls I need into the > core. These then call my JSON utilities library functions. If it were > easier to replace the built in ones in the core with user-added ones, > that'd be neat. > > As is, I've gone and updated Evan's Formula plugins & am very lose to > having my JSON plugins running on 5.1.20-pre (see other announcements). > > So, I'm comfortable saying we'll soon have the tools to start exploring > this space. > > Best, > Joshua Fontany > > On Thursday, July 25, 2019 at 4:15:56 AM UTC-7, Jeremy Ruston wrote: >> >> 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 >>> >>> 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 <[email protected]> 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 [email protected]. >>> 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]. >> 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/a9836c4a-cc21-4ae2-8f6c-0b07011e185f%40googlegroups.com.
