[TW5] External individual tiddlers via iframes?

[Mat]

An idea with potential use for e.g documentation and much else. (...if it is at all doable)

iframes are nothing new, but I just realized it's possible to - almost - make external tiddlers, such as from tw.com, appear to be tiddlers in my own TW:

 <iframe src="http://tiddlywiki.com/static/TiddlyWiki"  width="640 height="480"></iframe>

...or, if the "static" is omitted, it even works pretty well with an ulr to a live tw thanks to the focusing  (i.e scroll down) to the specific tiddler, or the topmost tiddler if many, and the sidebar is squeezed up above it so it's not seen. Eg:

 <iframe src="http://tiddlywiki.com/#TiddlyWiki"  width="640" height="480"></iframe>

Note: In HTML 4.01, the width could be defined in pixels or in % of the containing element. In HTML5, the value must be in pixels. (ref.) I notice the text wraps nicely though so there is no horizontal scrollbar, at least for me, so you can exaggerate the width value.

Obviously, the shown tiddler/s is not interactive with the surrounding TW - which could actually be used as an advantage: For instance, a site (like) tw.com could iframe and sandbox externally located plugins but still allow edit view for manual copying to ones own tw. People could send a mere link (via email?) with the url of a tw-plugin they've developed or even just found somewhere, and the local site could host a gallery of sandboxed display items. And meta-data could be added locally (..or via the email?)

Or documentation tiddlers for that matter. For a site like tw.com there could be a reviewphase where a document is viewable but not yet accepted to the actual site (to have it interact with the local tiddlers) until some criteria is met. Even external meta-data could be appended from yet other urls, i.e yet other people could bring input about the external tiddler.

Now, I'm wondering if it is possible to isolate the text/content from such an external tiddler? I presume there's no url but maybe there's something the local tw could do to shave off the surrounding tiddler or to remote-transclude the html element? In this way one can avoid the less pretty double titles that result from the iframing of a tiddler as described above. I figure there should be some advantage that the imported content is not just anything but a tiddler, i.e standardized and in a form we're 100% familiar with.

...alternatively, to create a local tiddler template that does not have a title, or at least doens't show it. I.e so that the iframed tiddler totally fills up an empty tiddler "shell".

And, who knows, if the "remote-transclusion" of a specific html-element is possible, then maybe it's possible to evaluate it's content and have it recreated locally. Perhaps a risk with text-box content even if I see value in it. A more innocent, but very valuabe, application would be to do so for the tags. You get the original tags but can edit and add your own to fit the local tw needs.

A bit like tiddlyweb, I think.

Doable or Pie in the sky?


<:-)

[Tobias Beer]

Hi Mat,

 

For an example see...

Reopen Tiddlers On Startup

And the corresponding macro + stylesheet...

$:/macros/static

$:/styles/static

Best wishes, Tobias.

[Mat]

You're kidding me - WOW!!!! And so recently at that! I promise I had no idea about it, I feel silly now!

Ok, that looks GREAT. And you did get the very text field only, I have no idea how, I can't tell from looking at the macro but maybe that is not where the inner workings are defined.

Now things are getting very interesting. I will try the following, maybe later tonight:

Imagine there could be a "trusted tree" building up from nested iframes. A bit like inclusion on TiddlySpace. A "top site" owned by person A could have an iframe like that, pointing at a specific tiddler (named T) on a tw  owned by someone that A trusts: B.

They agree B will in this tiddler put in iframes linking to plugins he recommends. This means A delegated this task to his trusted friend. Now, B can do the same thing with a third friend, C, but B sets up this connection, i.e an iframe, inside T (!!!)., perhaps under B's own recommended plugins.

C's recommended plugins will then propagate up to T, i.e in A's tw. All parties can obviously delegate to as many as they wish, potentially building up a tree of trust very fast.

If this works, it means it should be very easy to build up a complete plugin repository of all existing plugins. Of course one would need ways to eliminate copies.

Any spontaneous thoughts before I try this out? Or, rather, try to try this out. I don't even know if iframes can nest, so maybe I'll hit a wall right away.

<:-)

[Tobias Beer]

I don't even know if iframes can nest, so maybe I'll hit a wall right away.

Well, just try to iframe your iframing content and see what that brings...

At some point, the browser will need to stop recusrively embed things, or else. ;)

Best wishes, Tobias.

[David Gifford]

Is there a way to create an iframe that grabs only the title and text fields of a tiddler?

[Alex Hough]

Tobias,

Mind boggling - there so much to see in the way you've done this

Alex

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Ruston]

iframes are cool and fun but the way that they embed content is limited. Visually, iframed content appears as part of the parent document. However, internally, it's wrapped up in an impermeable protective membrane that makes it impossible for the host page to actually access the iframed content.

What we really need is "remote transclusion", where TiddlyWiki dynamically loads remote content as tiddlers. That means that the remotely loaded content will be available to list widgets and so on. All we need is a CORS enabled server to make this work.

There are a couple of techniques we can use to do that, and it's definitely on my list.

Best wishes

Jeremy.

--

Jeremy Ruston
mailto:jeremy...@gmail.com

[Mat]

On Sunday, November 23, 2014 9:55:42 AM UTC+1, Jeremy Ruston wrote:

There are a couple of techniques we can use to do that, and it's definitely on my list.

Absolutely super to hear!

As far as I can see, this will revolutionize TW somewhat like the internet revolutionazed the PC. The labour of arbitrary and manual copy-pasting files between PC's (analogous to how a TW user gets e.g plugins today) became instead more a labour of filtering and organizing among potential input.

<:-)

[Tobias Beer]

Here is another example of using iframes...

http://tb5.tiddlyspot.com/#Widget%20Browser

It allows you to select an entry from a dictionary and then have the url constructed from that.

Have a look at the bottom of that tiddler.

Best wishes, Tobias.

[Tobias Beer]

Hi Jeremy,

 

What we really need is "remote transclusion", where TiddlyWiki dynamically loads remote content as tiddlers. That means that the remotely loaded content will be available to list widgets and so on. All we need is a CORS enabled server to make this work.

There are a couple of techniques we can use to do that, and it's definitely on my list.

That would indeed be a whole different ballpark, to have some server serve or relay remote tiddlers, even lazily loaded.

Best wishes, Tobias.

[Mat]

On Sunday, November 23, 2014 2:55:49 PM UTC+1, Tobias Beer wrote:

http://tb5.tiddlyspot.com/#Widget%20Browser

It allows you to select an entry from a dictionary and then have the url constructed from that. 

Brilliant! Could let you have a list with document titles and, assuming they are in reality titled

"$:/documentation//tutorial/beginner/widgets/<searchword>"

i.e using the introduced "titlepath" policy, there could be a dropdown menu for each "level" in the titlepath. Or a multi level popup where you're presented a new sublevel after each selection. In this context I think multilevel popups would actually make sense - you're spelling out the titlepath (and url). Because the acutal iframe content can't be evaluated, this setup would require hardcoded titles to all potential tiddlers in the (e.g) Documents category on tw.com.

Another variant would be a search box that, if dedicated to documentation, is preset with a filter and thereafter use the user query. I.e the user types in query "browsewidget" and because he has previously stated he is a beginner (perhaps in Controlpanel where he wrote his signature name) and because the searh box is dedicated to documentation, he gets a resulting list filtered on all those three values. (ie the documents on browserwidget for beginners).

Could also be used for e.g plugins or anything!. For the sake of this discussion, take plugins: Each plugin on source tw (presumably tw.com) is namelisted in the users tw but with attached meta data. The user writes, say, "navigation" and all titles containing that metadata are filtered out. Add to query and... you get it.

And the list of plugin names would be a thing continously updated by the community! A plugin developer adds his plugin url plus a lot of meta data to include it. Users updates his source database tiddler whenever.

...and other users can add meta data to this plugin too!

It would take some place where people can add nothing more but the source url and the meta data into a list or table of some sort. Could maybe done in a plublic google docs document I think. I've set this google doc to public and "anyone can comment" but I'm not sure how comments appear - can you add stuff to the fields, but not delete? That's what I'm hoping for. This would mean anyone can just copy paste it into their local source title list tiddler to update it. Ideally something more elegant than a google doc, perhaps something that you throw away an email to and it's added automatically.


<:-)

[Tobias Beer]

Hi Mat,

While doing baby-steps in terms of actual traveling and destination-like-specs... your idea definitely has it's appeal... stuffing metadata into the core (or even fetching them from someplace) and use some remote-rendering voodoo to fetch the applicable contents either via intermediary iframes or directly, in the sense of what Jeremy suggested, as a proxy-server-kind-of thing to request and access actual contents.

The critical part being the actual MetaData authoring process... which could be yet anohter GitHub repo with a meaningful folder structure and a chron-job that mangles all the meta-bits every now and then into a tiddlymeta.json type of thing to be loaded / updated by the click of a button.

Best wishes, Tobias.

[Mat]

Must go to bed but this is just so cool.

I just realized an iframe is only necessary if you want to preview the tiddler/s. You're just searching a local tiddler with a list, in your own TW! And I even think you don't even need to involve proxy stuff or strict assuming the already existing import feature can be made to identify urls from each item in the list. The structure could maybe be very loose.

But if nicely laid out, and the, say, plugin author follows some standard, including providing multiple urls to things like tumbnail and description, the list tiddler could be designed to apper just like any other plugin site! And we have the import feature already so a Install button next to each. And it's all in your own tw!!!

...AND the idea can be used for almost anything! Themed such lists; "the plugin list" "the beginners toolkit list" themes, mathstuff, sex, drugs and rock'nroll - whatever naturally arises. If Jeremy doesn't like rock'nroll on the official site, there could be one single agreed upon place place hosting all "unofficial lists". The only type of stuff I see need for some thinking is for more collaborative stuff, like core documentation to get a consistent style, avoid redundence etc.

On tw.com, instead of loads of actual plugins or loads of links to arbitrary tiddlywikis in the wild, there are a few tiddlers with mere lists! Sure, there may pop up lists in the wild but that's no problem at all because contrary to the current problem with plugins and websites in unknown places, an item on a list can be on multiple lists!

Surprisingly simple. As far as I can tell, the only real difficulty is how people should add to the list and not mess it up. Kind of the same problem as discussed for documentation in the other threads. But then, for some lists maybe there will be list moderators who take care of lists with subjects they care for. The rate stuff is added is probably not very high for an average list so maybe the moderator could even accept list contributions via email (as I think pmario suggested for documentation). An ambitious moderator could even make the list tiddler snazzy with other stuff for his little special interest group. And it's in the interest of the special interest group to keep their favourite list updated.

Hm, why didn't we come up with this a long time ago. Just a few silly list that someone moderates and gives to Jeremy so it can be downloaded from tw.com. Am I missing something?

<:-)

[Mat]

One more thing:

Arbitrary, community initiated lists dedicated to topics, opens up to focus on content in addition to tw itself. I hear mortals care about such matters.

Think we're on to something...


(...just great, another 3 hour sleep night).

<:-)

[Mat]

On Sunday, November 23, 2014 at 9:55:42 AM UTC+1, Jeremy Ruston wrote:

 

What we really need is "remote transclusion", where TiddlyWiki dynamically loads remote content as tiddlers. That means that the remotely loaded content will be available to list widgets and so on. All we need is a CORS enabled server to make this work.

There are a couple of techniques we can use to do that, and it's definitely on my list.

 

I just found a really nice article on "HTML imports" which sounds like something very useful for us. Quote:

"HTML Imports, part of the Web Components cast, is a way to include HTML documents in other HTML documents. You're not limited to markup either. An import can also include CSS, JavaScript, or anything else an .html file can contain. In other words, this makes imports a fantastic tool for loading related HTML/CSS/JS."

<:-)

[Jeremy Ruston]

Hi Mat

> What we really need is "remote transclusion", where TiddlyWiki dynamically loads remote content as tiddlers. That means that the remotely loaded content will be available to list widgets and so on. All we need is a CORS enabled server to make this work.

> There are a couple of techniques we can use to do that, and it's definitely on my list.

I've now prototyped an approach that I think can work for these "remote transclusion" scenarios. The prototype takes the form of the new plugin library in 5.1.8. It works by loading the target resource into an IFRAME and then communicating with it via window.postMessage().

In 5.1.9 and beyond we'll build out the federation features to do more than just plugin importing.

Best wishes

Jeremy.

[Mat]

On Friday, February 27, 2015 at 9:44:47 AM UTC+1, Jeremy Ruston wrote:

I've now prototyped an approach that I think can work for these "remote transclusion" scenarios. The prototype takes the form of the new plugin library in 5.1.8. It works by loading the target resource into an IFRAME and then communicating with it via window.postMessage().

In 5.1.9 and beyond we'll build out the federation features to do more than just plugin importing.

This is incredibly exciting! I've re-listened to hangout #79 where you elaborate on the plugin library and some federation ideas. Out of curiosity, can I ask what makes you choose particularly windows.postMessage()? In trying to read up a bit, I found this nice comparison and overview of different techniques and they mention MessageChannel as better than windows.postMessage() (note quick summary at bottom of page). MessageChannel can apparently be used in all browsers, except by default in FF but it can be enabled there alos according to caniuse.

Thank you! I think this will prove revolutionary for TW.

<:-)

[Jeremy Ruston]

Hi Mat

> This is incredibly exciting! I've re-listened to hangout #79 where you elaborate on the plugin library and some federation ideas. 

I'd be keen to discuss it further in future hangouts.

> Out of curiosity, can I ask what makes you choose particularly windows.postMessage()? In trying to read up a bit, I found this nice comparison and overview of different techniques and they mention MessageChannel as better than windows.postMessage() (note quick summary at bottom of page). MessageChannel can apparently be used in all browsers, except by default in FF but it can be enabled there alos according to caniuse.

Ah, I hadn't come across MessageChannel. It does indeed seem to address issues that I've been experiencing with the postMessage implementation. Browser support is not bad:

http://caniuse.com/#feat=channel-messaging

But I think the inconvenience of setting up Firefox support may be a decisive factor against using it at the moment. (Bear in mind that the primary benefit of MessageChannel is simpler development and less code. In our case, we can pay the price for using postMessage in the pair of reusable components that encapsulate it within the TW federation architecture.

Best wishes

Jeremy.