innerWiki plugin & the meaning of recursive

[@TiddlyTweeter]

The innerWiki plugin is MOST interesting and exciting (https://tiddlywiki.com/prerelease/plugins/tiddlywiki/innerwiki/#%24%3A%2Fplugins%2Ftiddlywiki%2Finnerwiki).

It is lot more than a smart experiment by a very clever A+++ student.

The original idea was to make photo-snaps on the node version. 

But its a lot more than than that potentially (https://tiddlywiki.com/prerelease/plugins/tiddlywiki/innerwiki/#%24%3A%2Fplugins%2Ftiddlywiki%2Finnerwiki%2Fexamples).

Give it a try and come up with some ideas so it can get shaped into real utility ...

To give you an idea, this screenshot shows a wiki running INSIDE ITSELF where I changed its name and palette independent of mother...

In The Quine

Josiah 

[@TiddlyTweeter]

repeat for email ...

[TonyM]

Josiah,

I have covered some scenarios in this thread Help from Web Developer - iframe interaction

I have identified some scenarios for embedded iframes, even  the innerwiki plugin, I will share, as suggested by you.

Please forgive me for my rampant imagination, these ideas come from real life challenges.

Given, a Parent wiki, even a single file wiki can spawn an innerwiki with a subset of tiddlers

1. In the parent/outer wiki Accept some settings, Generate a seperate wiki based on the settings, in which a user can enter their input and save it to disk. Basically the parent wiki can be a TiddlyWiki factory. It can generate multiple editions from the one edition and with access to the resources / data of the parent, at least at creation time
1. Spawn an inner wiki which is a standalone wiki containing the results of a process designed in the parent wiki - in effect generating report wikis perhaps for distribution into an intranet.
1. The report wiki can be a light wiki, only with the results, not the tools to generate the results and could allow for a chinese wall with multi-client outputs.
2. It could even include active plugins disabled in the parent wiki.
2. Generate a TiddlyWiki as a Document/Website (full or template) in an innerwiki, giving it a unique filename, serial number and other features (metadata Stored in the parent wiki as well) then save/export the document. The parent wiki can hold a set of templates for the required tiddlywiki documents, and the document can store reference to its parent. Thus every wiki built is automatically known about by the parent "generating" wiki.
3. Generate "forms" in smart wikis, and allow the answers (in Serial number uniquified tiddlers) to be emailed in response (Ie the parent need not be writable), and imported by the owner of the parent.
2. Spawn an innerwiki identical to the outer wiki (all tiddlers), install a plugin to the innerwiki and test it sandboxed, from the parent. Optionally migrate changes back to the wiki or save it out and replace the parent.
3. Publish a parent wiki, that spawns innerwikis with generated tiddler sets, or test data. Users can then replicate there "problems" and "Challenges" in a defined wiki or data set, that that all users can also generate. So if I am having trouble with a special toc, I can test it inside a common wiki and share my broken tiddler and the named data set others can replicate.

Questions arising

1. Could we save and reopen an innerwiki injecting new content the second time, or harvesting changes within the innerwiki when it was away with another user?
2. Could we allow innerwikis to be saved into the server hosting the parent wiki?, node, AWS or php for example. 
1. As a hosted Tiddlywiki solution
2. The creator could then own the generated wiki but not the parent.
   
3. Could we generate an innerwiki with access to an authentication process, that allows the current browser session to be authenticated, then exit that innerwiki and continue within the now authenticated parent?

With a view to continued innovation!

Regards

Tony

[@TiddlyTweeter]

It was very interesting seeing that under Firefox Windows, running Timimi saver, the "innerWiki" saved fine to a new name.

[@TiddlyTweeter]

TonyM

As you know I'm not so tech. So this thing is like interesting witchcraft to me :-)

I did notice you can pass settings into it on startup via $:/data

I'm wondering if it could be used to test layouts for mobile phones on desktops?

That seems a simple test case to get clearer how it works?

But, how would you do that?

Best wishes

Josiah

[@TiddlyTweeter]

For those interested, I tweeted about the "#innerWiki" #plugin on #Twitter ...

https://twitter.com/TiddlyTweeter/status/1098242310712766464

https://twitter.com/TiddlyTweeter/status/1098244675926978560

https://twitter.com/TiddlyTweeter/status/1098247207910891527

In The Quine

@TiddlyTweeter

[TonyM]

Josiah,

I have not used it enough in pre-release to be totally literate with innerwiki but you will simply ensure sufficient tiddlers are specified in $data widgets to generate your innerwiki.

On test layouts for mobile phones, this sounds almost exactly like why Jeremy developed this plugin.

Note: Innerwiki allows

	Width in pixels of the virtual screen for rendering the embedded wiki
	Height in pixels of the virtual screen for rendering the embedded wiki

So it will be idea for what you ask, simply force the screen size you want, It should go straight into mobile mode if the theme etc.. do so.

Regards

Tony