Jeremy, I can see having subWikis, may be part of the answer but critical to many of the ideas I suggested is they are interactive, thus I favor your idea of somehow removing the iframe from the refresh tree. Could it be so simple as tagging a tiddler to be "ignored" (no need to explain why not, if not), just if we could there may be other applications. A form of deferred rendering, perhaps a render on demand button on a given tiddler, there are some applications where such a feature may be practical and desirable, and there are others where a refresh button would be helpful, so perhaps they could be combined. I am think of cases on import or editing of large tiddlers, we want to save, but not realise the changes yet. Like when taking notes and doing the save but keep editing.
Would one way be somehow opening the innerwiki in another browser tab/window , and in someway put it into an alternate "refresh" tree, One of my favorite early mods to TiddlyWiki was cloning the "Open in New Window" and making a "move to new window" which closes the the tiddler in the story as it is opened in the new window. I do understand the volatile nature of innerwikis, and perhaps I would be happy to deal with that, but perhaps it is true it would not be practical if it is part of a user solution, however; - If a wiki is read only as in the demo <https://tiddlywiki.com/prerelease/plugins/tiddlywiki/innerwiki/>, the user *can not* write over the existing one and in my chrome a download occurs, and in FireFox I get to choose the name and folder. This is very practical for distributing innerwikis, and given your recent enabling of setting the download name we could use the data widget to set the different filename. - Also if using innerwiki to generate wikis, then allow the user to save it, and that is all they are doing, the volatile nature is not important, they do it, and can easily redo it. Best wishes Tony On Saturday, 16 February 2019 19:28:28 UTC+11, Jeremy Ruston wrote: > > 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] <javascript:> > https://jermolene.com > > On 16 Feb 2019, at 07:32, TonyM <[email protected] <javascript:>> > 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 > > 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 > > 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 >> >> <https://groups.google.com/d/msgid/tiddlywikidev/a0a709df-8c73-4eb2-ab90-133d6b1cab31%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > 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 > > <https://groups.google.com/d/msgid/tiddlywikidev/a6d64762-ed2b-437f-b226-e16c0314a7eb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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/86db8efc-ec6f-45bc-83e7-c4054038a8a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
