I couldn't find this specific project in the forum (I may have overlooked it):

How could we go about creating an html page outline? Not editable, of course, but expandable and contractible? So as to have the same basic abilities of an outliner application?

I'm thinking in the lines of Stretchtext ( natematias.com/stretchtext/ ), with a few adjustments to the original project (there are a few issues that have to be addressed, like overlapping text when two expandable paragraphs are opened simultaneously and some minor formatting problems).

However, TB's 4.6.2 version doesn't seem to export Nathan's Tinderbox sample of stretchtext correctly, (I might be doing something wrong, who knows)... has anyone updated the code?

If not stretchtext, does anyone have another solution?

====
On a second note: this is my first post in this forum. But I have been with you guys for a while.
My regards to you all!

I think I've found the breaks. These aren't a fault of the original author, TB has moved on meaning some code renders differently or not at all.

Problem #1. In export template "prefix-suffix.html", v4.6.2 doesn't like this line:

^if(#linkedFrom(Prefix/Suffix))^

...as it treats the slash in the prototype note's title as a division, to no useful result (no HTML ouptput). However, the code works if you re-write the line as:

^if(#linkedFrom("Prefix/Suffix"))^

...or, as #codes are now depreacted, as...

^if(linkedFrom("Prefix/Suffix"))^

FWIW, a clearer way to write the above - as it show the actual evaluation being made - is:

^if($Prototype=="Prefix/Suffix")^

...noting that the '==' equality operator is syntax new to v4.6+. The 'margin-notes', 'prefix-suffix', and 'subheading' templates all make this slightly oblique use of #linkedFrom to test for the current note's prototype.

Problem #2. Unless you publish to the supplied export folder - thus overwriting the supplied example, your output will lack an 'elements' sub-folder holding at JS and CSS files needed. For now, simply copy paste the 'elements' folder to your output folder.

Personally, I've moved away from external templates unless many different TBXs will share the same templates; of course editing one template to fix an issue will affect all ouptput using it which may - or may not - be desirable depending on your needs and style of work.

I also prefer to keep the CSS as exportable notes so I can quickly find and check code. However, with the JS files as above if you are sharing the code across many TBXs' output then there may be more sense in manually placing the code in the export location; you're unlikely to be editing the JS code as much/often. If you are using a modern JS framework (Prototype, jQuery, MooTools, etc.) then the size if the JS libraries may outweigh your TBX HTML output so internal storage in the TBX would bulk your document unnecessarily. All of which goes to show there's no single 'right' way to to things with TB export!

Problem #3. Image export. When I first tried the export in v4.6.2, the image used in the exported 'Writing Tinderbox Stretchtext' note export edit's image to a different name/location than the HTML page expected.  I did wonder if it was some side effect of the alias of 'including images' confusing TB.  Aliases now export as separate files and I'm not sure if that was true when Nathan wrote his example. I can't repeat the problem, so may be if you export a second time this issue will go away! Tip: when writing a doc like this it can be handy to explicitly note the TB version used - though I'm as guilty as anyone of forgetting to do this in my examples.

Problem #4. Less a problem than a puzzle. I can see no apparent need for the alias of the 'Prefix/Suffix' prototype in the 'System Prototypes' container.  I don't think it does any harm, but nor do I think it should be there.

@Marcelo. It sounds as it you want an outline with headings that have hidden 'contents' that's shown/hidden on a mouse-click. If that's the case, IMO, stretch text seems a too-complex solution as it's attempting to resolve a different problem; you'll end up doing a lot of content surgery that's not directly related to your output needs. If you read Nathan's original notes, the demo isn't written for nesting more than 2 (more?) levels, certainly not N levels [added later]:
Quote:


I'd also add one more question - how much data are you looking to export?.  If you do everything in one browser page you may find that if it's a lot (not a fixed figure!) the page may not perform as you want.

My initial guess is you want a recusing template where each note is output as a heading that when clicked shows/hides its body copy ($Text) and the headings for it's children - allowing drill-down. CSS is used to mirror outline level by increasing the left margin for each level.

The bits that get harder are expand-all and collapse all with will need some JavaScript DOM functions to loop through the document showing/hiding stuff.

Anyhow, it's easiest to draw out what functionality you need/want before passing samples around.

Collapsible outlines are truly an amazing didactic tool. One could, theoretically, fit a rather fancy summary of, say, a Dostoievsky's novel, in a single page!

I like to demonstrate to my students the notion of multiple substructures within a complex literary work, which helps them visualize the work as a whole when levels are collapsed OR explore it in finer detail as needed, when expanded. The possibilty of synthesis and analysis within a single text... a revolutionary resource, indeed! Only a century ago, this could arguably be considered the critic's impossible holy grail.

That's fine but be aware that at some point page size, host resources or browser memory leaks (if not careful with DOM scripting) may limit extensibility. How many notes are we talking about? 10s, 100s, 1000s?

If you do go the collapsible oultline route, this article might be useful. You'd need to expand the JS to add showing of title & text vs. title alone but the article is a good starting point using unobtrusive JS methods making your HTML templates simpler to write.

@Mark B.: Quote:


Can you show us how?

There is no reason you couldn't have a practically unlimited number of "stretchtext" links that load into iframes. What this would mean is that the initial load of the HTML page could be as small as you want for initial presentation. The disclosure of certain passages would then load on-demand and in-place. This is precisely what I do for the links marked "load" in my zombie bibliography. (For example, the link for "Anonymous. A "Capitalistic Sublime?." and the second and third links for Balibar.)

I would like to offer more information than simply to say "it's possible," but it will take time to put together a proper tutorial/walkthrough. The Tinderbox document, the HTML templates, and the JavaScript code are considerably complex and will take time to abstract for general purposes.

As Mark B. suggests, put together the requisite HTML and JavaScript first. Then abstract that structure into Tinderbox. If you do it right, you will be able to add new items by merely assigning a prototype and adding text. (That is, all the gory HTML and JavaScript details can [and should] be templatized and [consequently] automatically and uniquely generated.)