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 On Saturday, November 22, 2014 1:01:44 PM UTC-6, Tobias Beer wrote: > > 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 <http://toc.id>* to *hx.id > <http://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]] <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.
