Hi Jeremy, As I am fearing this to become rather lengthy, I am opening this thread to address Jeremy's response at this thread <https://groups.google.com/d/msg/tiddlywiki/6zBxrj4nV34/NucvoBSuscYJ> 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 > <http://www.tiddlytools.com/#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 <http://eucaly-tw5.tiddlyspot.com/#%24%3A%2Fplugins%2Feucaly%2Fmatchfilter%2Freadme> 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. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
