Help from Web Developer - iframe interaction

[TonyM]

Folks,

I had a hunch I could go further with HTML Javascript integration. But I need some help getting some interaction from or between items in an iframe.

If I place another tiddlywiki in an iframe I can drag and drop between both the current Wiki and the Iframe tiddlywiki.

Further to this I have have a html javascript solution in an iframe and I can use this to see the result and interact with this html java script. All good so far. 

The iframe can appear to be inside the tiddlywiki when in fact it is not really, so I could use this as a method to show  HTTP PUT and GET forms etc...

I can also use raw markup to "include" external files.

My Question to the tiddlywiki aware webDeveloper is what methods are available for me to improve the interaction between my html javascript in an iframe? 

• I can copy and Past, I can open in new window and print, but are there other ways of increasing the interaction such as a button to capture the content currently displayed in the/an iframe designed for data transfer, or somehow post something into a field or html id in the iframe ?
  
• Another path may be generating json, csv or tid files in the external javascript/html then provide a button to import that into the wiki. Perhaps even image selection or generation.
  
• I am also interested in providing php solutions in an iframe but want to establish how to integrate this with tiddlywiki.
  

Special advantages?

• Even on a read only wiki's plenty of read/update solutions could be developed using tried and tested web services
  
• On a NoteSelf or Read Update wiki the results can be "imported" into the users "version" from what ever services are presented in the iframe.

The more detailed you suggestions I suppose the better but do not hesitate to provide answers without too much detail as I simply need a starting point at present.

Thanks in advance

Tony

[TonyM]

Post Script.

You can see from the Original Post there is not only the iframe by which to interact, which I ask in this thread but other file import, include open read and write. For example I could write a json file that the external html/javascript/php processes and the the tiddlywiki can collect the results.

Note: This is not about loosing the single file model but allowing our wikis to interact with external systems/databases. If done correctly the integrity of the single file can be maintained.

Regards

Tony

[TonyM]

Another Question Arising.

When an Iframe is opened in Tiddlywiki, what is rendered becomes "static" that is it will not be rerenderewd if the underlying html file is changes. Is there a method to ask for this to detect a change and reload?

Regards

Tony

On Saturday, January 26, 2019 at 12:18:14 PM UTC+11, TonyM wrote:

[Jeremy Ruston]

Hi Tony

Browsers support a mechanism to pass messages between a page and the content of an iframe that it hosts:

https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

It’s pretty magical: it allows rich, asynchronous structured communication, and is widely supported on all browsers. Best of all, it doesn’t require the HTML files to be hosted on the same domain, as is required for XMLHttpRequst.

It’s actually the mechanism that drives the plugin library in TiddlyWiki 5. Loading the plugin library means loading an HTML file into an iframe and then using window.postMessage to ask it for a particular plugin.

Jed built on the same mechanism to make the Twederation prototypes.

Best wishes

Jeremy

-- 
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 tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
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/fa02b552-1c0a-49eb-93c5-a87ce85c9b28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TonyM]

Jeremy,

That is exciting to know. I will look into it, but it may be beyond my current skill set. I appreciate the federation approach and the servers but here I am keen to get single file/single file interaction, especially when single file can be so easy to publish.

Perhaps some generic tools for some really basic interaction or a tiddlywiki specific method need to be collected.

Of note is also the way Timimi uses the new browser methods which I speculate could be used  for inter wiki communications within browser tabs a bit like tiddlyclip.

We have so many existing possibilities and future opportunities with TiddlyWiki, its mind blowing.

As mentioned in my Smart Documents thread, I can see using an iframe to a service to obtain single use passwords, or write permissions or  passing back version forks and other information.

Regards

Tony

[TonyM]

Jeremy,

Is this mechanism available from a widget or macro to send to or receive messages as highlighted?

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.

Is the Data widget in innerwiki effectively like this?

Regards

Tony 

On Sunday, January 27, 2019 at 4:23:38 AM UTC+11, Jeremy Ruston wrote:

[Jeremy Ruston]

Hi Tony

Jeremy,

Is this mechanism available from a widget or macro to send to or receive messages as highlighted?

No. The only iframe stuff that is implemented at the moment is the plugin library support. To explore further will require JavaScript development.

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.

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.

Best wishes

Jeremy

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/9550702d-caf3-4131-a93e-66eee593ef21%40googlegroups.com.

[TonyM]

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

[Jeremy Ruston]

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

jer...@jermolene.com

https://jermolene.com

--

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 tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
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.

[@TiddlyTweeter]

Jeremy Ruston wrote:

... we'll need some clear scenarios first.

A lot of my time is spent replicating in TW what Firefox did via Add-Ons before the apocalypse.

--- A case would be a matrix of two wiki in iframes side by side you might d-n-d between?

--- Another case might be having frames of specific dimensions to test mobile layouts.

Just wondering

Josiah

[TonyM]

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

[Jeremy Ruston]

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

jer...@jermolene.com

https://jermolene.com

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/a6d64762-ed2b-437f-b226-e16c0314a7eb%40googlegroups.com.

[TonyM]

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, 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