<!-- Create several tiddlers with the same tag based on a filter that creates them -->
<$button>
<$list filter="[title[oils]][title[butters]][title[animal fats]]">
<$action-sendmessage $message="tm-new-tiddler" title=<<currentTiddler>> tags="fats" text="" />
</$list>
Make'm
</$button>
So the code above works, it adds tags to a list of tiddlers from the filter.
But it’s lacking parameterization which is what I attempt to add below, in the code that doesn’t work:
Filter: <$edit-text tiddler="$:/state/new-tiddler-filters" tag="input" default="[title[lye]]"/>
Tag: <$edit-text tiddler="$:/state/new-tiddler-tags" tag="input" default="alkali solution"/>
<!-- Create several tiddlers with the same tag based on a filter that creates them -->
<$button>
<$list filter="{{$:/state/new-tiddler-filters}}">
<$action-sendmessage $message="tm-new-tiddler" title=<<currentTiddler>> tags="{{$:/state/new-tiddler-tags}}" text="" />
</$list>
Make'm
</$button>
Is there anything I’m missing about pulling the filters or tag names from the edit boxes?
To use the contents of a tiddler as a widget parameter value, you need to omit the quotes around that parameter (i.e., only use the {{...}} syntax), like this:
<$list filter={{$:/state/new-tiddler-filters}}>
and
<$action-sendmessage $message="tm-new-tiddler"
title=<<currentTiddler>> tags={{$:/state/new-tiddler-tags}} text="" />
Also, as a general recommendation, instead of using $:/state/... to hold your inputs, I suggest using $:/config/leand00/..., so that you can easily distinguish between settings you have input vs. internal state tracking tiddlers.
enjoy,
-e
Just have a question on the $:/config vs $:/state debate. Aren’t $:/config tiddlers intended to be permanent and saved along with the rest of the tiddlywiki, while $:/state tiddlers are intended to be temporary and often discarded when saving and reloading the wiki?
In the context they are being used here, as a temporary reference for creating new tiddlers, I would suspect using $:/state or even $:/temp tiddlers would be prudent? no?
If you are using a single-file TiddlyWiki then $:/config and $:/state tiddlers (except for $:/state/popup/ tiddlers) are saved with the file. If you want your inputs to always be discarded upon save, then definitely use $:/temp
-e
Expanding on https://tiddlywiki.com/#Naming%20of%20System%20Tiddlers, my understanding of things is:
- $:/config/*
- There is nothing special about these tiddlers other than they are “system” tiddlers due to the “$:/” and are hidden from regular tiddler searches.
- $:/state/*
- These are saved like regular tiddlers when the wiki is saved.
- However, changes to these do not trigger the wiki as needing to be saved so no red save button and no warning on closing.
- Also, these tiddlers are not included in an upgrade when you drag your wiki over to upgrade.html.
- They are unmarked by default and you have to specifically manually mark them to have them migrate to the upgraded wiki.
- $:/temp/*
- Like $:/state/, do not mark a wiki as needed to be saved if they are changed.
- However, they are not saved when wiki is saved.
- So these are good for truly ephemeral info.
Hope this helps,
/Mike
I relation to the original request I see value in exploring a systematic solution to using tags to provide the addition of tags.
What do I mean?
Imagine a tag pill that appears on any tiddler matching a filter, for example if it is a todo item, be it a tag or field. Then by clicking this pill, the drop down list, lists each of the tags that also have the todo tag, these are the possible tags you may wish to add or remove (toggle) only on todo tiddlers eg done
- Simply to toggle these tags out of the box will be enough for many
However we can expand this to have secondary filters that determine what other items appear and even the opportunity to introduce sort order, actions on add and actions on remove a particular tag.
The key is to make this intuitive, so there is less need to document or describe this mechanism, so its easy to adopt by both the designer and the user.
So this would be a globalised and general solution for that, that gave rise to this topic.
I am thinking I will use a term I used previously and call these “action tags”.