TonyM,
It looks like we have a similar solution, but yours is more sophisticated
than mine. I only define the "field-type" field ("list" / "value"), a
"template" field ("<<tag>>", "<$ link />") used to display and a
"direction" field ("from" / "to"; if the field can be used to represent a
hierarchy, "from" means that the tiddler itself marks its children as a
"list" field, "to" means that the children mark the tiddler as their
parents, eg . "tags" field).
Definition of "tags" field:
title: $:/config/fields/tags
field-type: list
direction: to
template: <<tag>>
Definition of "list" field
title: $:/config/fields/list
field-type: list
direction: from
template: <$link/>
Definition of "color" field:
title: $:/config/fields/color
template: <input type="color" value=<<currentTiddler>> disabled> <$view
field="title"/>
Either way, it is clear that defining fields is necessary to make them
more flexible. I wonder what Jeremy thinks about that? It is certain that
these ideas are feasible, but it is questionable whether they get into the
core? If not, even though many plugins use this principle, each plugin
needs to be configured with its own fields, since they do not use a common
setting, but each has its own solution.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/2df66d8c-75c9-460c-ab40-94ef4edc7f8f%40googlegroups.com.
