Hi Jan > To parseTreeNodes sounds a little chinese for me...but I think I > understand. >
Yes, it takes some getting used to terminology. Think of it like that: You have wikitext and that is parsed by the TiddlyWiki core into a parseTree and then a widget tree subsequently constructed from that, which in turn eventually generates DOM elements for the browser to display, but not necessarily. Since TiddlyWiki does away with the focus on manipulating DOM elements directly, operating on a widgets architecture, there is a bit of a gap. With TiddlyWiki classic it was easy to do DOM traversal and manipulation with jQuery and so we could do all kinds of fancy stuff after the fact, meaning, after TiddlyWiki did its default thing with the wikitext. However, with the new architecture, we're a bit lacking on a general interface for developers to traverse the widget-tree-representation of your wiki text, e.g. so as to say "find that list and give me its list elements". Such a traversal may not even be desirable owed to the transient, stateless nature of widgets... which doesn't mean that they do not actually have a state, but that they can be trashed and recreated at any given moment... so if you have some other output that would depend on the current widget representation, there's a chance it would not notice that the thing it references and relies on to do further stuff actually changed from the first time it was created, e.g. that footnote index. So, with TiddlyWiki classic there were HTML / DOM elements like ULs and LIs (which we still have, of course) for which we could use simple jQuery selectors to address them. However, now we would need some simplistic equivalent to address the underlying list widget, so as to be able to then do magick with a possibly much safer and much more powerful encapsulation in the form of a widget, that provides well defined interfaces for actually handling it, e.g. when to refresh or recompute the state of that widget, etc... > If it is what Ithink it would put us all a big deal forward and could be > the basis for many things I try to build. > - a filter collecting Footnotes > - a way of transcluding/navigating to parts of Tiddlers > ... and thus new possibilities to present information stored in TWs for > example in Slideshows et cetera > So, that's the thing: you would need to be able to tell the TiddlyWiki core: - that right there is my "tiddler" in the widget tree - and in that thing being the "tiddler" rendered from that wikitext, go find elements matching this or that pattern, e.g. all list widget where some attribute is such and such - eventually return the corresponding widgets so that I can do fancy stuff based on what I'm given, e.g. with the list items ...presuming I know all about list widgets and how to get from the list itself to the items However, one core paradigm is that widgets are transient things by nature, especially their representation in the DOM. So, in general the philosophy would be to always work try and with the underlying wikitext first. And if that proves difficult, chances are you simply haven't sliced and diced your wikitext just enough for you to be able to address every single chunk of concern separately. To conclude with a much more practical example, let me put it this way: if you turned your footnotes into actual tiddlers, e.g. as $:/fn/the related tiddler/foo $:/fn/the related tiddler/bar and then retrieved it as: <<fn foo>> in the context of *the related tiddler*, then you could do all kinds of magick with those footnotes ...and all that would be missing is some simplistic plugin that, instead of using some markup in the tiddler, would go create those "under-the-hood"-related system tiddlers being the footnotes... which it would be most trivial to later on list with whatever eye-candy you fancy most. Based on a given list of chapter tiddlers being rendered each with their individual, related footnotes tiddlers you could as well easily generate one big list of footnotes. All you need is for your footnotes to be actual tiddlers. Hence system tiddlers since you may not actually want them to be searchable on their own. However, you could easily run into problems with the above approach if you ever chose to rename those titles. So, one crucial missing piece to safely model stuff like this, is that eventually TiddlyWiki will bring core support for every single (non-system) tiddler to have an auto-generated unique id, so it would be: $:/some-unique-id-12345/foo $:/another-uniqueid-54321/bar With the eventual tiddler being: title: some related tiddler id: some-unique-id-12345 Refer to <<fn foo>>. Am I making sense? 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 tiddlywiki+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e7f95d27-4dcc-4fab-bdce-eb968c8c07cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
