> While this is good for TiddlyWiki, especially those which are file:///
> based, it is less good for server-side storage systems that store
> individual tiddlers (rather than whole wikis).
I don't agree. The design that I have *already implemented* and which
is *widely used* in the community does NOT rely on any file-level
granularity. Just as with any other tiddler, each attachment tiddler
can be independently stored (e.g., TiddlyWeb), or stored as part of a
complete file-save action (e.g., TiddlySpot).
> * tiddler.text is either a data uri containing encoded binary stuff or
> remote URI which has the stuff
> * tiddler.fields[something] contains metadata about the binary stuff
> including amongst other thing an indicator that this is a binary tiddler
> * Core or CoreTweaked support for binary tiddler awareness in
> TiddlyWiki, such that refresh or edit of a binary tiddler enters a
> binary tiddler code path.
Except for your insistence on using custom tiddler fields, the
underlying design you propose is quite similar to what I have already
done. Instead of using custom fields to hold the base64 text-encoded
data and related meta-data, I used standard TW section syntax, plus a
single 'attachment' tag value to indicate the tiddler's "type". The
plugin adds 'binary tiddler awareness' for the core [img[...]] and
[[text|...]] syntax, so that a simple reference to an attachment
tiddler may be used in place of an external URL.
The plugin also provides two public functions, 'isAttachment()' and
'getAttachment()' that make it very easy for other plugins to directly
access the data stored in the attachment. Examples include:
ImageSizePlugin, ImagePathPlugin, PlayerPlugin, TiddlyPodPlugin,
SetIconPlugin, and several others.
As a general rule for TiddlyWiki, I *strongly* prefer NOT to obscure
the data in tiddlers by hiding them in custom fields unless there is a
*very* compelling reason to do so. Otherwise, it just adds
complexity, reduces flexibility, and blocks access to the information
from the document's owner.
In particular, using custom fields makes the information less portable
between documents, as it *requires* non-standard edit-mode handling
(to display/modify those fields), or at least non-standard tiddler-
saving actions (to re-interpret user input and add custom fields). In
contrast, tiddler sections are modified using the standard TW
interface, just like any other tiddler, and do not require any special
handling at all to be stored or copied, and individual tiddlers (or
sets of tiddlers) can be easily imported/exported between documents
without needing to support any non-standard editing/saving for those
tiddlers.
In addition, as previously noted, even without installing the
AttachFilePluginFormatters runtime support, you can still access and
even *render* any base64-encoded image data by reference to the
attachment's [[TiddlerName##data]] slice value, using slice-embedding
features, such as the <<tiddler>> macro.
For example, you could write a simple tiddler, [[ShowImage]],
containing:
/%
!out
[img[$1]]
!end
%/<<tiddler ShowImage##out
with: {{store.getTiddlerText("$1##data")}}>>
which invoke by writing:
<<tiddler ShowImage with: SomeAttachmentTitle>>
In summary: I don't see *any* net advantage to hiding attachment data
in custom fields. It seems contrary to the 'open information' nature
of TiddlyWiki, and makes it harder to share that information across
the entire TiddlyVerse, because it would be locked in to TiddlyWeb's
server-side representation, which will force TW authors to use custom
fields and non-standard editing, even for documents that are NOT
intended for TiddlyWeb storage.
-e
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To post to this group, send email to tiddlywiki...@googlegroups.com.
To unsubscribe from this group, send email to
tiddlywikidev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/tiddlywikidev?hl=en.
