Hi Jeremy, My proposition is that TW should be oriented towards a small consistent set > of inter-tiddler operations, without the complexity of intra-tiddler > operations that in any case encourage authors to overload tiddlers with too > much information.
One of the core strengths in classic TiddlyWiki is the ability to gather and mix and mingle tidbits from all over the wiki *easily*. While I can see how that a certain amount of flexibility may turn out confusing, having the following places to store and gather stuff from in clasic TW provided for a huge amount of potentiality... which has actually been used throughout the TiddlySphere. * tiddlers (generic, shadow, hidden via tags) * sections (visible, hidden) * slices (visible, hidden, different markups) * fields (hidden, visible) and via plugins even * data (hidden) * namespaces Now, I will not argue that those architectural provisions made way for some seemingly weird and probably inefficient implementations. So, I do certainly share the desire to reduce architectural complexity to the bare minimum. Looking at other wikis I don't quite see how you will get a round section handling and from a first gut-evaluation I would rather not like to see my wiki septuple in terms of tiddlers just because we now extract reusable sections into tiddlers of their own. The first problem would be how to easily name the child and refer back to the parent. I sure can see how, programatically speaking, this is the cleanest approach. It's just that in terms of UI, I would not want to see those tiddlers (by default) to show up anywhere. Their context is the parent tiddler. I guess you'd have to provided a way to have these subtiddlers without actually seeing them as separate entities, perhaps with a similar namespacing to what NameSpacePlugin provides (but perhaps only one level deep, e.g. parent > child). This opens up a number of questions... * What if the parent is renamed? * What about the aggregated view, just one level deep? ** Compare to http://docs.servicerocket.com/display/REPORT/Include+All+Child+Pages ** What about templates that define how such an aggregation is rendered? * Are those subitems allowed the full feature set? ** They'd need title, body, some reference back to the outer parent via a field reference... but what about tags, etc...? ** Can they have further (such "invisible") subitems too? *** Would we then need a treeview to easily navigate the ToC? Everyone would sure like that. *** It probably doesn't need a full-blown TiddlyDocs [3] but a contextual ToC in the info panel would be good. All in all, the route you propose sounds ok to me if it shifted the development focus on a generic tree widget that works with recursive or embedded lists of sorts and perhaps leaves out duplicates so that a tiddler only shows up once in the tree (or that all duplicate leaves are truncated), something like RelatedTiddlersPlugin[1] or x-plore[2]. Cheers, Tobias. [1] http://tiddlytools.com/#RelatedTiddlersPlugin [2] http://tbgtd.tiddlyspot.com/#x-plore [3] http://osmosoft.tiddlyspace.com/#TiddlyDocs ...what happened to it? -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" 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/tiddlywikidev. For more options, visit https://groups.google.com/groups/opt_out.
