[Idea] Export minimal wiki for iframes

[Anjar]

Hi!

Just sharing a tought: I am sometimes making tables or other elements for web pages and thinking: If only I could’ve made this element in tiddlywiki… And the solution in some cases is to actually create a tiddlywiki and include it as an iframe.

There are, however, a few downsides; a full tiddlywiki is rather large (especially if you want to have several of them) and the ui isn’t optimal (preferable responsive single tiddler view, read mode, no need for sidebar)

I wonder if anyone have had similar thoughts or needs, or perhaps have experimentet with minimal wiki with read-mode and no sidebar?

[TW_Tones]

Have a look at static tiddlers or exporting as static html. I can give more tips tomorrow.

[DaveGifford]

If you click on the TEXT of any line with an asterisk on this static page I created with TiddlyWiki this week (: Índice central giffmex), the slider will reveal an iframe of another static page created by TiddlyWiki.

[CodaCoder]

Sorry for the slight digression to the OP…

Nice Dave!

Add this to your css:

summary {
 cursor: pointer;
}

[TiddlyPatrick]

Hi @Anjar,

maybe you can copy the html code of the table in TiddlyWiki and past it into your webpage. I am not sure, if it goes into the right direction you want.

What I do: When I want to include a table from a paper, I simply copy the html code from the webpage and insert it into my tiddler. You could do the reverse thing by copying the html code from the table in the tiddler and paste it into your webpage. Here a short example (in low quality you can also use the shortcut Cntrl/Cmd + C / + V):

[Anjar]

Thanks for all your suggestions! I think I failed to describe the use case properly, so I made a short demo:

[TW_Tones]

@Anjar As I understand it you need to use the iframe because the content you want to imbed is interactive. It refers to more than one tiddler and needs to respond as if you were in tiddlywiki.

Some thoughts

• You could export the whole tiddlywiki as static html and at least linking to a page would load one static tiddler page at a time.
• If you host his on node every tiddler is also published as a static tiddler automatically, you just need another address to each tiddler (the advantage of this is they remain updo date an no export step is required.
• You could create your own export tiddlers template(s) designed to generate all the required HTML files you need, even to include Javascript but this is too complex except for special and repeat usage solutions.

I think there would be value if you step back and describe why you wish to do this or what are you trying to achieve in the end?, are you trying to incorporate tiddlywiki interactivity in a non tiddlywiki html page? Why not make that page or site a full tiddlywiki? What is your journey, rather than ask how to take the next step (perhaps this step is unnecessary or another path more appropriate).

[Springer]

This is an old thread, but it speaks to something I’d like to see. Whether or not it’s for an iframe, it would be lovely to have a middle-ground between these extremes:

• Static site (lacking in dynamic interactions)
• Full tiddlywiki (large file, with all code needed for authoring)

In other words, could there be a reduced-size dynamic html document that simply omits whatever won’t be needed by a non-authoring web visitor?

I understand that dynamic features still require some level of modifying tiddlers (to set temporary states, etc.). But edit templates, alternative unused palettes, various control panel interfaces, unused sidebar tabs, and presumably lots of other tidbits end up being so much “bloat” relative to what a web-viewing visitor needs.

It’s ironic that in order to make a non-confusing view-only / reader-mode interface for my students, I end up just adding code to my tiddlywiki, even though what they need is “less, not more” of the power of tiddlywiki.

What I imagine is something analogous to the ability to save as static html, but this time: save as dynamic read-only wiki.

Anyone able to estimate how much of a filesize difference this would make? Would offloading the unneeded stuff be comparable to the benefits of external-core? (Perhaps most of the benefits would actually relate to the core – in other words, an alternative leaner external core? But surely some other bits of unneeded authoring interface would be within plugins, etc.)

-Springer

[Charlie_Veniot]

Give this is spin as per the video below.

Go to the BASIC Anywhere Machine User Guide and Programming Reference: Charlie'sDocumentation for BASIC Anywhere Machine — User Guide and Programming Reference.

Go to the Keywords Reference, and bring up the “all keywords and special characters” tiddler.

Click on “CIRCLE” to view the documentation for that keyword.

Scroll all the way down to the examples section.

The examples shown in the iframe come from a different TiddlyWiki instance (the BASIC Anywhere Machine IDE.)

That is an almost almost 4MB TiddlyWiki showing content in that iframe. What do you think?

BAM Programming Reference: integration of code samples from BASIC Anywhere Machine

[Springer]

Charlie, this looks like a very thoroughly-developed resource… but I’m not sure I understand what’s going on behind the scenes here. Is this a case in which there’s a tiddlywiki being loaded (within the iframe) that has been “trimmed” so that the browser doesn’t have to fetch a full tiddlywiki worth of code?

[Charlie_Veniot]

Nope. Not trimmed. That’s unnecessary.

It is the full TiddlyWiki html.

However, not displaying the TiddlyWiki interface at startup.

[Charlie_Veniot]

Take a look at the following tiddlers:

https://basicanywheremachine.neocities.org/BAM_IDE#View%20Program:%5B%5BView%20Program%5D%5D%20%5B%5BBASIC%20IDE%5D%5D

https://basicanywheremachine.neocities.org/BAM_IDE#Startup%20Actions

https://basicanywheremachine.neocities.org/BAM_IDE#TW%20CSS%20override

EDIT:

AND

https://basicanywheremachine.neocities.org/BAM_ProgReference#tEx

[TW_Tones]

@Springer

What I imagine is something analogous to the ability to save as static html, but this time: save as dynamic read-only wiki.

I believe this is partially achieved by externalising the core both for the primary wiki and any other wiki within it. I expect any further attempts to reduce the core size is too complex an effort to bother with. There are two alternative approaches I can think of,

• Use the innerwiki plugin to generate the “sub wiki” with only the required components. Not sure if you can externalise the core here.
  • You can save the innerwiki using its save button, that you may hide/disable for the final result.
• Currently static tiddlers, even wikis are generated using templates within tiddlywiki to generate HTML files. There is nothing stopping you from designing your own template to generate anything you want. It all depends on how detailed you want to go.

I personally would endeavour to try and generate static content without dynamic features, that you can then include, or iframe in the primary wiki.

• Then you could progressively add interactive features to this once static output template but to keep the core out of it you will need to apply your HTML and JavaScript development skills to crafting this “non-tiddlywiki” output.

[Springer]

@TW_Tones

I personally would endeavour to try and generate static content without dynamic features, that you can then include, or iframe in the primary wiki.

Ah, the point I did not make clear: the iframes I need to employ are not within a wiki at all, but within a university LMS (moodle).

I’ve already moved to tiddlyhost’s external-core option.

So I suppose my next step is combing through the wiki for older content that can be deleted. (This is a project that was born in TWC, and has been under continuous development since 2008. TiddlyWiki does make it easy to let older content gather dust in the background! I recently did use a sort-by-size process to find and remove the biggest obsolete tiddlers, but haven’t tried hoovering out all the small detritus.)

[TW_Tones]

@Springer

Ah, the point I did not make clear: the iframes I need to employ are not within a wiki at all, but within a university LMS (moodle).

I suppose by definition the iframe can be anywhere. You just need to be able to access

[Springer]

My point is that static tiddlers are not at all what I want (though for a TW within a TW the resort to static bits might have been less of a loss); I want the students to have the engaging and dynamic web-visitor experience of a TiddlyWiki (albeit in read-only mode), and was simply looking for more ways to trim the loading time.

Given your pessimism about how hard it would be to isolate the bits of code relevant only to authoring, I won’t hold my breath. I’ll keep having them load the whole (external-core) tiddlywiki via an iframe, with my recently-added read-only css to make the interface as uncluttered as possible.

[Springer]

Ah, I should clarify that I’ve already solved various “minimalist display” challenges; my site is now nicely uncluttered, thanks to read-only css.

The worry inspiring my post here was the slow loading time for visitors. My hope had been that a “minimal wiki for iframes” (as the OP put it — but really it’s about minimal wiki for read-only visitors) might actually be one solution here. I’m now persuaded that the only reasonable step in that direction is the external-core approach (which I’m already doing).

[Charlie_Veniot]

I had thought about trying other options, but the solution I have is fast and convenient: no fuss, no muss, dynamic, single-source info. Works for me.

Best wishes with whatever approach you adopt.