[TW5] and sections ...revisited (sorry, long post :)

[Tobias Beer]

Hi Jeremy,

As I am fearing this to become rather lengthy, I am opening this thread to address Jeremy's response at this thread with respect to me stating...

Actually, I think I'll be satisfied once I managed (to hire a crew to help me) to port SectionLinksPlugin to tw5. ;) 
Despite any dreaded performance concerns, there are just too many highly useful usecases involved with sections...

• section-toc for tiddler foo, providing clickable links! (even back to the toc from the heading)
• $link to section foo, from tiddler bar, too
• $list section foo of tiddlers tagged bar
• (edit section foo)

First of all, allow me to thank you, Jeremy, for taking an inquisitve stance on the topic and for inviting discussion. I know your critical stance towards sections and I am hopeful that you might eventually come to a slightly different opinion, if only once a SectionPlugin of a beast sees the light of day.

That implies making sections behave exactly like tiddlers.

It's a possibility, not a necessity, and certainly not a requirement, although one could make it one.

 

That's problematic because it means that all the behaviours we've built for using and manipulating tiddlers need to be re-engineered to work with sections. In some cases that's extremely tricky.

It could indeed be problematic but then there is no need to have sections entirely as addressable and manageable as the tiddlers that supposedly hold them. Of course, it could be complicated if one wanted to address a section that was actually dynamically created, e.g. via $list, as that would imply wikification before being able to do so, e.g. via a parameter that says "render:true" instead of merely inspecting the basic wikitext.

Anyhow, here are some rough sketches for how to implement the above usecases...

1) section toc:

Had I jQuery or the likes, here's what I would try...

1. user puts <<toc>> whereever he likes, e.g. the top of the tiddler
   
2. <<buildtoc>> is appended and run from ViewTemplate section with list-after:body
3. finds all h1...hx from tiddler
4. sets id's or rel attributes at headings so as to have a reference for where to navigate
   
5. build and render toc
6. use js function to link from toc.id to hx.id and back using the above attributes, NO href!

2) link to section foo

1. decide on a syntax, e.g. [[tiddler§§foo]]
2. display tiddler, passing the info to the display method that there's a section to scroll to
• after all, there is some scrolling right now, too, so the function is there
3. have the display method find the first mathcing heading element after rendering
4. if found, scroll to
   

3) list section foo of filtered tids

1. filter tids, e.g. using $list
2. use regex to extract section similar to how TWc or matchfilter can do it
3. wikify

4) section editing

• should basically be similar to Eric's plugin for TWc, except for the internal functions to be called, of course
• that is, if sections are being modeled as wikitext, rather than a JSON dictionary stuffed into a section field
• might be problematic as TiddlyWeb for example limits the length of fields for optimization reasons

For example, how would you make a location hash link to a section (eg http://example.com/#my-section-12)? 

There's no syntax within the location hash to identify the string as being a section name and not a tiddler title.

http://example.com/#[[foo$$bar]]

If there was a tiddler called foo$$bar, then we'd go to that, of course. Otherwise we go to section bar of tiddler foo.

But, I would not worry about location hashes too much for now. I would certainly not use actual anchors.

The only syntax to identify sections would be specific to tw, so it knows how to interpret [[foo§§bar]]

Another example, to use the $list widget to list all sections of tiddlers tagged bar would require us to be able to process section names within filters. That implies that sections would need unique IDs - once again, making them meet the definition of a tiddler.

I'd say unique ids are not essential or even required, at all. Sections are not tiddlers, but if neither the section nor the tiddler exist, the display handler would simply show the non-existing tiddler as it does right now. Using the first matching heading is just fine, or skipping entirely if not found. Also, I'd want the regex to, by default, match until the next heading of same level ...and, optionally, as TWc does, until any next heading (or end of the body).

Basically, TiddlyWiki is a mechanism for manipulating tiddlers. 

Everything about it is predicated on the idea of a tiddler as the smallest unit of content.

I understand that tenet and I see the merits. But it's also going to weird lengths, if I may say, e.g. configurations could and probably should be stuffed into meaningful datatiddlers / dictionaries, rather than be individual tiddlers cluttering the namespace.

Anyhow, we've noticed in many a previous discussion, that there are usecases where users desire to have slightly bigger "documents" without all the hassle of linking and fiddling with linking, tagging, list field ordering and whatnot.

 

Your requirements describe something else: a mechanism for manipulating sections of monolithic hierarchical documents.

That would indeed be the opposing end of the scale and might, in fact, be something some users actually end up doing, although perhaps inadvisable. But there's a middle way, I presume. One where I can have link "Summary" sections, have a "Summary" section listed in an in-tiddler toc, extract "Summary" sections or even edit them individually ...without necessarily having the biggest tiddlers of all times in front of me. :)

 

I understand why these requests are framed in terms of implementing sections but I'd really like more insight into the underlying needs.

It's really basic presentation, navigation and data mgt for me. Sections are SO much simpler to manage ...for the user! At least, once they're available, people will just love them, for sure. Some may do what feels like abuse to them, but so can people abuse the mighty tiddler just the same as it is right now and turn it into a big whale roaming the TiddlySea. ;)

Is the desire for tiddlers with long, hierarchically structured content because they are easier to edit as a single run of text?

Editing is actually NOT the focus. Editing long tiddlers is, in fact, more cumbersome, that is without the ability to edit individual sections.

Or easier to import?

Easier import, most definitely. Such tiddlers could, in fact, alternatively, be stored as a JSON construct under the hood and only displayed as a bunch of nested sections.

Consider: [[foo$$bar$$baz$$mumble]] ...four levels down, all neatly addressed, even the hierarchy... BUT each section possibly with the SAME title, e.g.: [[foo$$foo$$foo$$foo]] ...no need to have or check for unique names, perhaps only at the same level.

Such an approach could likely be a much more powerful alternative over thinking of sections merely as rendered output. And, it might simplify splitting sections into actual tiddlers, or overloading them with section fields, etc.

However, using a JSON construct will definitely be an entirely different approach over using what could be called classic sections... and perhaps overkill. But then we already do have plugin tiddlers that package a bunch of components... so, well... it's not like the mechanisms need to be entirely reinvented.

 Or is it because the single tiddler is easier to read on screen than a sequence of tiddlers?

Effectively, for the user, the desire is that the output looks just the same. In one scenario, with loads of individual tiddlers, a number of tidbits need a lot of steps to manage. In the other, there is a slightly bigger chunk with added features as to linkability, editability, extractability accross the tw.

For example, had one a naming structure like...

MyBook

MyBook / MyChapter

MyBook / MyChapter / MyPage

...then there could easily be a conditional ViewTemplate section that uses the current tiddlers title as a prefix for a filter and display a toc or even the entire contents of the tiddlers underneath... no matter what the delimiters.

Here's a playground for that...

http://sections.tiddlyspot.com/#:GettingStarted%20%5B%5BEl%20Libro%5D%5D

...and the first problems I immediately ran into... :)

https://groups.google.com/forum/#!topic/tiddlywiki/MleQ4GNCqt0

Best wishes, Tobias.

[Tobias Beer]

Expanding on...

 

However, using a JSON construct will definitely be an entirely different approach over using what could be called classic sections...

Again, perhaps total overkill, but if JSON was the way to go, here's an idea for implementing JSON based sections...

<!--§§
{

    "sections": {

        "foo": {

            "text": "blablabla"
            "status": "approved"

        },

        "bar": {

            "text": "mumble mumble",

            "tags": "[[really?]] [[wow]]"
            "modified": "ok, that goes too far, but maybe not, after all, why not?!? the adapter could be quite generic"

        }

}
§§-->

Et voilà! The magic of hidden sections. ;-)

By all means, compared to classic section handling, that's perhaps a whole different ballpark.

But it's probably a lot easier to handle / index / manipulate computationally.

You certainly don't want users to edit this stuff in the text editor.
So I wouldn't even load it there ...but remember while editing the main body

and then provide a section editor for each section, only one instance per tiddler at a time.

What would also be thinkable are hidden dictionary "sections" in usual tiddlers, like so...

<!--##
foo:bar
baz:mumble
frotz:gronk

##-->

Either way, I'd only process one instance each of sections or dictionary JSON per tiddler. After all, there's no need to have more of them, so any matching algorithm would only take care of the first instances.

Best wishes, Tobias.

[Tobias Beer]

Expanding on...

Ok, you can probably scratch those hacky markup proposals.

If anything, JSON sections of a tiddler hidden from the main body editor would probably be something more like this...

<$sections>
{}
</sections>

and a data section more like...

<$data>
foo:bar
baz:mumble
</data>

Best wishes, Tobias.

[Tobias Beer]

Some toying with what could be a $section widget...

a) create link to section...

<$section link="tiddler§§section"/>

b) render section toc for tiddler here...

<$section toc="render"/>

c) build section toc assuming a previous <$section toc="render"/> widget exists in the context (would be placed in a global viewtemplate section after the body

<$section toc="build"/>

d) provides a button that opens a section editor

<$section edit="tiddler§§section"/>

Or a [section[]] filter...

e) lists all summary sections up until the next heading, regardless of its level (TWc)

<$list filter="[section[summary]]"/>

f) lists all summary sections up until the next heading of the same level

<$list filter="[section:full[summary]]"/>

etc...

Best wishes, Tobias.

[BJ]

Hi Tobias,
there is a classictransclude widget that is used in the tw2parser plugin (it can be used to transclude sections and slices)

Cheers
BJ

[Tobias Beer]

there is a classictransclude widget that is used in the tw2parser plugin (it can be used to transclude sections and slices)

Thanks BJ, I'll have a look at the code.

[Tobias Beer]

Another usecase for sections can be formula-fields...

<$section title="bar"/>
<$list filter="[let: (fieldA + fieldB) * (1 + fieldC) / 100[]]"/>
<$section>


...so that...

{{foo§§bar}}

...returns some calculated output, thus functionaing like formula fields either with respect to a tiddler's fields or as rollup-summary-fields with respect to properties of tagging or listed items or entirely arbitrary items.

Best wishes, Tobias.