That’s ok for the user awareness. I can live with a button that says “do you really want to load xxx.tid?” . So far as I know the tiddler in the node.js version form tiddlywinks will be loaded also “by request”.
I tried it with the _canonical_uri and it works with html files but not with *.tid files.
The problem here is that the loaded tiddler-file is in a “nutshell”. If I have a link in this tiddler (as html) to the origin wiki it is not working. That means I can use them only if there is no interactions.
That’s no option. The browser open-file dialogue is an operating system dialogue, that is activated by the browser. Browsers do not have javascript functions, that will allow us direct access to file-based information.
There is a file API for browser extensions, but they still need user interaction to be triggered. …
I’m not at home atm, so I can not test any SharePoint API functions. As I wrote it needs a bit more studying of the docs and some experiments. … The whole thing is interesting, since you are not the first one, that has to use SharePoint in a “locked down” enterprise environment.
@stefan_from_germany just keep in mind that TiddlyWiki Leverages the universal client, the browser, and it is this client that has being targeted for scams and advertising for decades now. If we can find a way to take control of the import or export of content from a website (or tiddlywiki) without the users knowledge, we will have found something the scumbags of the world look for every day.
I feel your pain because we are just trying to make it easy for the users of our software.
However rather than trying to take on the very difficult challenge, to change the world, I think you can get an equivalent by other means. As usual it depends on the users, their level of engagement, skills etc… how far you need to go.
But first, I am not sure the premises in your first post are completely valid.
Perhaps import them all “to start with” and only show a subset.
Provide a mechanism to detect use and hide chapters not accessed
Not withstanding the above,
interaction with another source or wiki can be done through an iframe or better yet a plugin library (see below). Drag and drop packages between wikis in the same window.
As raised earlier, with an iframe the chapter may never be installed, just viewed.
You may be able to generate an innerwiki designed for accessing content choices (needs more research).
A plugin library can be used to browse and list, install, or remove chapters packaged as plugins but, you may want to build a custom view of the import plugins from library, to hide the normal plugin and/or import interface and add a delete/remove button (but I still question the necessity).
Content, if not too big, can be loaded from data: links, or bookmarklets either in the browser or packaged for other html pages.
