> 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.
