> Okay it's good to know that there is the option of staying with > wikitext and also the option of having dual wysiwyg/html. > So the choice will have to be made on a per-tiddler basis. > > What I am concerned with is that plugins that traverse or use wikitext > (the source of a tiddler) will have to be tailor-made for either html > or wikitext. Is there a provision to make them format-unaware?
In TiddlyWiki5 two subtle parts of the macro processing have been more explicitly separated. The first is the text processing to render the source text of the tiddler to a DOM representation. For wikitext tiddlers, this is the wikification process. For HTML tiddlers, this is the conversion from a string of HTML to a DOM structure representing the same HTML. The second is the processing of dynamic content within that DOM representation. The archetypal case is when something that has already been displayed needs to be changed due to a change in the store. For example, when a tiddler is first created, any links to it need to change from italicised to non-italicised to indicate that the tiddler now exists. This processing to refresh the display is inevitably a DOM-based operation. Bother of these layers of processing exist in classic TiddlyWiki, as well, it's just they're not so well separated. This architecture means is that precisely the same macros can be used within HTML tiddlers and wikitext tiddlers. For macros, in classic TiddlyWiki, the rendering process was fixed; all macros are rendered as a <DIV> with additional attributes giving the macro parameters. So, macro writers just had to write the DOM-based refresh mechanism for their macros. > The data plugin I mentioned in the twdev thread was a prime example. Parenthetically, and I should have replied to the original thread, I've come to believe that aggregated tiddlers can be restrictive. I've found the best rule of thumb to be to split things up into the smallest chunks that make semantic sense, and then to use tags/fields/slices etc. to tie them together into multiple dynamic aggregations for presentation and processing. I appreciate your concern about the restriction of needing to name every tiddler. In many cases the best way around seems to be to use synthetic names (much as a database assigns numerical ids for records in some situations). > I'd like to be able to extract records or sections, create tiddlers > out of them, and then invoke tiddler functions on those temporary > tiddlers. It is possible to make the infrastructure for this (records, > tiddlers and slices) oblivious do the data format, that is to say that > that these generic methods would support multiple formats. A html > record could be embedded in a special tag, whereas a wikitext record > could be embedded in a {{record{ ...}}} wrapper. The code would handle > all of it and the macro that is responsible for the data collection > would be unaware of the native format. It sounds like some of the complexity you've got comes from the nesting of tiddlers inside other tiddlers, and the need to re-invent how to encode the metadata. I've found that pulling back to a simpler, non-hierarchical model avoids this problem. > All macros would then need to call existing generic functions for text- > manipulation, all of which are tailor made to work on several native > formats. If some macro gets back a piece of text, and calls a wikifier > on that, the wikifier would know whether it is wikitext or html and > proceed accordingly. But this is difficult since text is just text and > it cannot identify itself. In the case of tiddlers, in TW5 there's a MIME type to identify the content type. > What I really don't understand is that you've gone the multiple-format > + html/wysiwyg approach and not the wikitext/wysiwyg approach. I presume by "wikitext/wysiwyg" you mean the approach of round-tripping from wikitext to wysiwyg and back again? I do think about that approach, particularly being aware of the WIKIWYG project that originated at Socialtext. The roundtripping is a hard problem (but then again so is parsing what browsers leave behind when you type and paste into an contenteditable="true" elements). Best wishes Jeremy -- Jeremy Ruston mailto:jer...@osmosoft.com http://www.tiddlywiki.com -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.