Hi Tony Good stuff!
The fundamental issue that would prevent most of those applications working today is that innerwikis are volatile: if the tiddler containing an innerwiki gets actively refreshed then the innerwiki will be deleted and recreated. I think that the only way to get around that would be to keep the innerwiki iframes in a separate part of the DOM that isn't subject to the refresh process -- that's how the plugin manager works. A related problem is that any changes within an innerwiki are lost. There's nothing stopping an innerwiki saving changes, but not all savers make sense -- the innerwiki and the parent wiki have the same path and filename, and so would overwrite one another. Interestingly, I think most of your examples could be reimagined as saving a customised sub-wiki, one that doesn't necessarily have all the same tiddlers as the parent wiki. Right now, one can only apply a filter when saving to choose which tiddlers should be included but one could imagine re-using the <$data> widget to enable additional tiddlers to be generated for inclusion in the saved file. Best wishes Jeremy -- Jeremy Ruston [email protected] https://jermolene.com > On 16 Feb 2019, at 07:32, TonyM <[email protected]> wrote: > > Jeremy, > > 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 > 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 > 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. > 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. > It could even include active plugins disabled in the parent wiki. > 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. > 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. > 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. > 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 > 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? > Could we allow innerwikis to be saved into the server hosting the parent > wiki?, node, AWS or php for example. > As a hosted Tiddlywiki solution > The creator could then own the generated wiki but not the parent. > 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 > >> On Tuesday, 12 February 2019 19:04:41 UTC+11, Jeremy Ruston wrote: >> Hi Tony >> >> It's good to broaden the understanding of the benefits and pitfalls of >> iframes. One takeaway from this thread is that using iframes is a well >> understood technique in the developer community, and TW already uses them in >> several roles (plugin library, viewing HTML tiddlers, innerwiki, >> Twederation). >> >> We can continue to discuss exposing iframe functionality as primitives that >> wikitext authors can experiment with, but we'll need some clear scenarios >> first. >> >> Best wishes >> >> Jeremy >> >> >> >> >> >> -- >> Jeremy Ruston >> [email protected] >> https://jermolene.com >> >>> On 11 Feb 2019, at 22:59, TonyM <[email protected]> wrote: >>> >>> Jeremy, >>> >>> Thanks for your response. >>> >>> >>>>> The "send to" may be the minimum needed as when constructing a HTML page >>>>> we can easily add the javascript, but if it were available as both send >>>>> and receive within TiddlyWiki users may also be able to use this >>>>> possibility? It would be understandable that it were a plugin if the >>>>> support is not already built in due to the plugin library. >>>> >>>> I don't quite follow the question. The communication used by the plugin >>>> library is bidirectional, if that's what you mean. >>> >>> As I understand this, the bidirectional aspect is from and to outer and an >>> inner wikis. >>> It would be helpful if we can "access" in a widget, the communication >>> used by the plugin library so a super user rather than only developer can >>> access this. >>> If the content of iframe is non tiddlywiki such as a html/javascript page >>> we need the matching code to embed in it to also enable the communication. >>> >>>>> Is the Data widget in innerwiki effectively like this? >>>> No, the way it works is that the data widget is completely passive; it >>>> doesn't do anything except collect its attributes and render its children. >>>> Other widgets that contain those data widgets can process each one, >>>> extracting the attributes. >>> >>> OK Thanks. >>> >>> Thanks for patiently responding to my questions that are clearly somewhat >>> from a place of ignorance. I am exploring the possibilities for new and >>> expansive applications of TiddlyWiki for which I do not necessarily have >>> the jargon for. We are all a little naive when moving into a new field. >>> >>> Best wishes to you too, >>> Still in Oxford? I would love to visit some time. >>> >>> Regards >>> Tony >>> -- >>> 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 post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/tiddlywikidev. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywikidev/a0a709df-8c73-4eb2-ab90-133d6b1cab31%40googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. > > -- > 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 post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/tiddlywikidev. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywikidev/a6d64762-ed2b-437f-b226-e16c0314a7eb%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/026862DB-F261-49A2-98AF-3F7CF8FD9EBC%40gmail.com. For more options, visit https://groups.google.com/d/optout.
