Tag depending layouts and fields


I’m not sure this is the right category, for this (apologies if not) but I wonder if anybody could help me to understand how to create tiddler templates which changes depending on tags selected?
I’ve seen this in @clsturgeon amazing Memory Keeper which I use for my genealogy. I would like to make use of this for other projects which require different data entries.

I tried to understand the Memory Keeper but struggle with identifying the java script tiddlers which make all the magic happen.

Any help would really be appreciated, thank you!

A tutorial might be required to describe this. I need a tech writer to articulate my ideas and implementations. But I’ll give it a go. Where is my chatGPT window? :slight_smile:

Your screenshot shows a complementary set of data entry fields that appear in Edit Mode of a tiddler. Users (and I) found it difficult to use the “out of the box” edit fields. First, users have to know what fields to select and then are limited to single-line text data entry. The objective of these complementary data entry fields is to show the user what fields are available based on how the tiddler is tagged and where possible, make data entry selectable rather than data entry.

You mentioned JavaScript. From what I recall, there is no JavaScript to generate this behaviour.

Here is a list of things I defined to do this:

  1. Write one or more EditTemplate tiddlers. I currently use one. However, it has become long and cumbersome. So, review and refactor as you go.
  2. Write a custom StyleSheet tiddler specifically to manage what fields appear for each tag. What will be confusing in Memory Keeper, is that I do not have a dedicated tiddler for this, I buried the style for this in one huge MK StyleSheet tiddler. However, I’ll try to break that down for you.

In Memory Keeper this cumbersome “EditTemplate” tiddler is titled “$:/plugins/cls/mk/field-selector”. It should be renamed. It was originally named and written to generate pop-up “selection” fields. More on this later. In the end, this tiddler manages various types of fields.

As mentioned in MK this tiddler is named: $:/plugins/cls/mk/field-selector and tagged: $:/tags/EditTemplate

The first logic in field-selector allows the user hide / show TWs edit fields. This is optional.

<span style="float:right; font-size:12px;"><$reveal text="hide" default={{$:/state/fieldeditor}} type=match><$button set="$:/state/fieldeditor" setTo="show" tooltip="show TW edit fields">{{$:/core/images/unfold-button}}</$button></$reveal><$reveal text="hide" default={{$:/state/fieldeditor}} type=nomatch><$button set="$:/state/fieldeditor" setTo="hide" tooltip="hide TW edit fields">{{$:/core/images/unfold-button}}</$button></$reveal></span>

It creates a button to appear on the far right to show/hide the TW fields.

Then I created a container to hold all the field definitions. This is done to hide all or any number of items. For example, if no tags exist or tags exist that are not associated with my fields, we want to hide these edit fields. That wrapper is:

<fieldset class="fieldset" id="fieldsetid">


Everything inside this will define what we want to appear based on tags.

In MK the first thing listed are the legends. These are group boxes. In your screenshot I see the group box “Person Fields”. This is done with:

<legend class="fieldlegend" id="personledgeid">Person fields</legend>

The class and ID will get configured in the StyleSheet. Create a legend for each type of tagged tiddler you want to configure.

Next comes the laundry list of fields. Put them in the order you want them to appear on the screen.

Here is a simple single-line edit field to enter a URL:

<div style="width: 100%" class="fieldtext" id="urlid"><br/><label class="cuslabel">URL</label>
<$edit-text class="tw-edit-texteditor mkTextEdit" tiddler=<<currentTiddler>> tag="input" field="url" />
<span class="helptext">Enter URL for document.</span></div>

The class and IDs used here get defined in the StyleSheet.

Here is multi-line text box:

<!--Description field-->
<div style="width:100%" class="fieldtext" id="descriptionid"><br/>
<label class="cuslabel">Description</label>
<$edit-text class="tw-edit-texteditor mkTextEdit" rows="4" minHeight="2em" tiddler=<<currentTiddler>> tag="textarea" field="description" />
<div class="helptext">Use this field as tooltip on trees.</div>

How about a dropdown list box:

<!--Source state -->
<div style="width:100%" class="fieldtext" id="sourcestateid"><br/>
<label class="cuslabel">State:</label><br/>
<$select tooltip='Choose source state:' field='sourcestate' default='new'>
<option>under review</option>
</$select><br/><div class="helptext"><$reveal state="!!sourcestate" type="match" text="new">The source has been added to the collection, and you have yet to commence the review process.</$reveal><$reveal state="!!sourcestate" type="match" text="">The source has been added to the collection, and you have yet to commence the review process.</$reveal><$reveal state="!!sourcestate" type="match" text="under review">The source is currently undergoing review.</$reveal><$reveal state="!!sourcestate" type="match" text="reviewed">The review of the source is finished.</$reveal></div></div>

The complex data field, which I have not seen anyone use, is the multi-selection pop-up. The dropdown example above shows a static list. The multi-selection pop-up that I wrote is used to populate “title” fields, those fields that contain 1 or more references to associated tiddlers (that already exist). No one wants to type these in, you want them to be selectable. So, I wrote a macro “field-selector” to manage these. I elected to use a non-modal pop-up, because I wanted to be able to navigate away from the pop-up to generate a tiddler if it does not exist. Then go back to the pop-up to select the new tiddler. I will not put the code here for that macro. (You’ll find it MK). However, here is an example on how I used it. This provides a pop-up to select one or more spouses:

<!--Spouse Selector-->
<$set name="ov" tiddler={{!!draft.title}} field="spouse">
<$macrocall $name="selector" id="spouseid" tagger="person" field="spouse" label="Spouses" originalvalue=<<ov>> dialogid=<<dialogid>>/></$set>

Now to the StyleSheet. Here are my default settings:

.fieldtext {display: none;}
.helptext {font-size: 9px; }
.mkTextEdit {width: 100%; }
.fieldselector { display: none; }
.fieldlegend { display: none; }
.fieldset { display: none; }

Then I’d associate tags to the fields. For example, to have the description field (along with two other fields) appear on the person tiddler (in Edit Mode) I’d add this to the StyleSheet:

[data-tags~="person"] #fieldsetid,
[data-tags~="person"] #personlegendid,
[data-tags~="person"] #descriptionid,
[data-tags~="person"] #captionid,
[data-tags~="person"] #akaid
  display: block !important;

This also forces the field set wrapper to appear and the approapriate legend (group box) to appear when the tiddler is tagged with person.

There are classes here that I use that you need to change to meet your needs. For example, cuslabel for me is:

.cuslabel {
  background: <$text text=<<themecolor>>/>;
  color: white;
  padding: .2em .5em;
  margin: 2px; 
  border-radius: 4px;
  border: 1px solid #666;
  box-shadow: inset 0 0 0.1em #fff, 0.2em 0.2em 0.2em rgba( 0, 0, 0, 0.3 );

Users can customize the colours in my solution, hence the background color.

After all that. Wouldn’t be better if there was a plugin to do all of this for us? Something we configure and it just does this magic.

I hope this helps.


Hi Craig,

That’s brilliant thank, you so much. :slight_smile:

See SuperTag plugin, auto-generate a field editor on view template

If list filter returns empty (no matching $:/SuperTag/TraitTag) then it will not show the content.

@linonetwo That looks interesting, I will take a look

@clsturgeon Hi Craig, I think I understand how this work now, thanks again for the detailed instruction. I’m also trying to create these nice looking layouts for all the different categories of data such as person, events and so on (see screenshot), but I struggle to figure out which system tiddlers are responsible for this.

@ChrisW For any tiddler, the first thing to look for are tiddlers tagged as $:/tags/ViewTemplate.

In MK the primary system tiddler is $:/plugins/cls/mk/ViewTemplate. The person tiddlers are referenced here. However, the person tiddler, unlike others, has two view templates: one to show the header ($:/plugins/cls/mk/template/personheader), the other to show the rest ($:/plugins/cls/mk/template/person).


@clsturgeon Thanks Craig :slight_smile:

@clsturgeon I got a questions regarding the /EditTemplate/mktitle tiddler. This tiddler is responsible for the selection of tags which appears when a new tiddler is created. I sort of understand how it works and tried to create new tags. For some reasons there is an issue when I try to create new tags.

Basically what I did was copying an existing part of the code and changed the tag names and created all the tiddlers which show the tags after a specific tag was selected.

I used this one

<$list filter="[all[current]tag[source]tag[newspaper]]">
<$set name=tagcount filter="[all[current]tags[]count[]]">
<$reveal text=“2” type=“match” default=<>>

{{$:/core/images/info-button}} Select type of entry in a newspaper (optional):
<$list filter="[tag[$:/tags/mk/source/newspaper]each:list-item[text]sort[title]]" variable=tagg><$macrocall $name=showpill tagg=<>/>

and changed it to this:

<$list filter="[all[current]tag[event]tag[disaster]]">
<$set name=tagcount filter="[all[current]tags[]count[]]">
<$reveal text=“2” type=“match” default=<>>

{{$:/core/images/info-button}} Select type of disaster (optional):
<$list filter="[tag[$:/tags/mk/events/disasters]each:list-item[text]sort[title]]" variable=tagg><$macrocall $name=showpill tagg=<>/>

I created the tiddler with the tags relevant to disasters. The blue box with the info text appears but fro some reasons the tags won’t show up.

Quick reply: I think you may want to look into control panel > Info > Advanced > Cascades > View Template Body

These are much more flexible and powerful than a set of ViewTemplates so tagged.


1 Like

@ChrisW Have you reviewed the steps for creating custom events?

Memory Keeper — Help (clsturgeon.github.io)

Then search for “Custom Event Types”.

I have not reviewed the code to determine its behaviour. There should be little need to modify or generate any code.

Let me know if the documentation does not help.

Similar actions are available for others things, like places and organizations.


@clsturgeon Thank you :slight_smile: I managed to create new event categories and they work well.

I still have an issue with the mktitle which controls the tag selection sequence. It works well for the top level but as soon as I select a tag (from a tag group) depending on two previous selections no tags show up anymore.

I basically copied the code that creates the same behaviour for the source/newspaper/(tag group).

Yeah, custom event tags are only supported at the 2nd level. You want to define a 3rd level custom event? I assume you want to define “disaster” as a lower level to what tags?

I’ll see what I can do. This makes sense MK support this without you having to code it.

Aside: did you upgrade to build 11?


@ChrisW Try replacing the mktitle tiddler with this one, but only after you have upgraded to build 11 (since that is what I tested this on):

$__plugins_cls_mk_EditTemplate_mktitle.json (10.8 KB)

You can create 2nd level (or primary) custom event types as previously described. To create a 3rd level event type (or secondary) custom event the procedure is similar; create a tiddler tagged $:/tags/mk/events and put the custom event tag in the text field. Then create a field named: eventtag and list one or more parent tags in the field value. For example, put “disaster” in the text field, and then in eventtag put “death marriage execution”. This means that eventtag can contain references to MK event tags and your custom tags. Then, whenever a tiddler is tagged “event” and “death” or “marriage” or “execution” you should see an option to select “disaster”. I hope this makes sense. If this works, we can implement the same for places, sources, and others.

1 Like

@clsturgeon Thanks Craig, I will try this.

@clsturgeon I think I’m on build 11. I downloaded the latest version.

@clsturgeon Made some progress and got all the things working so far. I was wondering what make the tabs (family, events ect.) under the header box show up? I can see that these are defined in the templates but they I think they need something else to appear?

That something else is CSS. MK has two view modes: Tabs and List. Tabs view is typically for onscreen viewing, but not ideal if you want to print a tiddler. The idea of list view is hide the tabs and list out tab content, so it can be printed. Users may have other users for the list view.

You likely noticed person tiddlers have two view templates, one for the harder the other for the rest.

I have refactored tabs a bit for build 12. Too much duplicate code, plus a few bugs.


@clsturgeon I guess its the collections/css that does this?


By default tabs are hidden:

.clstabs {display:none}

But, when the tabs are enabled (a setting; hotkey is Alt-Ctrl-T and Alt-Ctrl-L):

The CSS found at the bottom of the $:/plugins/cls/mk/css is supposed to show “List” or “Tab” view. It does work, but I have reviewed the code, and it is not working as I expected. There is an undocumented feature where the user should be able to use, a dataview parameter on the URL to define the “default”/starting view as either “List” or “Tabs”. This is not working; until now. I just fixed it. However, look at that code under the comment of “Tab definitions”.

Thanks for the continued questions.