I am looking for a mechanism whereby I can load my data JSON tiddlers from an external file at load time, a bit like an ‘include’ facility. This then stores and allows manipulation outside of tiddlywiki with the current set of JSON tiddlers loaded when the tiddlywiki loads.
My reasoning is that my environment is both a content management system an an online access system. TW handles the second with ease but I am concerned about it handling for first. From my, limited, experience with TW, I am of the opinion that TW is a single user at a time editing environment whereas our guns wiki could be maintained by many people at the same time.
I have written a JSON editing program that takes all the tiddlers for a single gun exported out of TW into JSON and allows its editing and then re-importing back in to TW. That works, at least in test mode but still remains more cumbersome than I would like.
My thinking about the JSON tiddlers held externally to the TW is that this set could be hosted on a CMS platform, like Dropbox or Google Drive, edited by anyone at any time and then loaded into the TW at run time.
In a worst case scenario, I could envision the JSON tiddler set being imported back into the runtime TW by a ‘wiki master’ at some time they determine the TW should be updated. I do this now with a TW of artworks for which I have created a Filemaker Pro database for maintenance and a script for exporting into JSON followed by a TW import.
All thoughts and suggestions from the group appreciated.
This attribute name is one provided by w3schools so requires some support features in you tiddlywiki. I have used the html object tag and others to display external content in a Wiki. Some inclusions can be achieved using html tags in tiddlers with an appropriate RAW tag in tiddlywiki, the trick is then addressing what has being included in “TiddlyWiki Script”.
However how you can then act on what you include, is limited
I agree that “Content management”, more to the point multiple editors is not the smoothest for TiddlyWiki and though solutions exist its difficult to implement through nodes and proxies on the internet, MWS may have answers.
Standard single file wikis
I have done a proof of concept where a read only user makes changes on a live published wiki including adding and modifying content even images then hits submit generating a downloaded JSON of the changes and emails it to the website owner. The the owner reviews and applies the changes, to the published version. We could build some tools around this, both before and after export.
What you describe, is what we use to develop TW. The dev system allows us to maintain every single tiddler as a .tid file in an edtions/tw5.com/tiddlers directory and subdirectories. It builds into a single file wiki with a command like tiddlywiki editions/tw5.com --build index, which will build a single file wiki, that you know from tiddlywiki.com
For developing and editing TW content we locally do this: tiddlywiki editions/tw5.com-server --listen, which allows us to open and edit the wiki locally, using http://localhost:8080/
We can also use an external editor like VSCode to maintain TWs core code and also the .tid files. So those files can be edited and version controlled, since every file is text only. The .tid file format is much simpler to read by humans, than JSON. So every text based editor can be used to edit.
So it’s easy to modify every single tiddler locally and easily build it into a wiki run one of the above commands again.
You mentioned FileMaker. So you could do the same. You probably could use it as your editor instead of VSCode … Just a thought.
We used FileMake at ~2000 +/- 5 years. Did not know it still exists. I think it could also export .tid files instead of JSON if needed.
If you have a look at the tiddlywiki.info file in the server edition, you will see, that there is a includeWikis parameter, that would allow you to have several smaller wikis, that could be worked on at the same time. Once finished a --build command can combine them into 1 wiki, or every “sub” wiki can be published on its own. … or whatever you need.
We use git for version control. You probably could do so too …