Rather than hide-body=yes/no

I’d much prefer a body field

  "title": "My Tiddler",
  "body": "my-field" // default "text", special value "--HIDDEN--"


Interesting idea. I have made additional text area fields in a tiddler and with the new cascades you can easily replace the current body template to do what you want but you will need a condition to trigger it but that can be the body field. In which there may not be a need to default to text.

What do you percieve to be the advantage of this?

I would write this into the body

<$transclude field="my-field" mode="block"/>

hide-body has a different usecase

Of course. That’s why I didn’t say “Instead of…”

Well, I don’t have a use (yet) it’s more a “build it and they will use it” kinda thing. hide-body is a bit of a dead end, and miopic for a system that’s otherwise eminently malleable. Whereas the above is more open to customization (I believe).

It’s no biggy. Just an early morning brain hiccup :slight_smile:


The new cascade-mechanism is much more flexible than hard-coded fields.

You can create a new cascade tiddler tagged $:/tags/ViewTemplateBodyFilter with a list-before : $:/config/ViewTemplateBodyFilters/hide-body filed, that provides a filter that calls your custom body-template for every field you might want to use.

Also see: https://tiddlywiki.com/prerelease/#Cascades There are some HowTo’s listed at the end of the tiddler.

1 Like

Yes, like @TW_Tones said.

However, correct me if I’m wrong, cascades are…

  1. a lot more work to produce this simple, per-tiddler kind of switch

  2. less discoverable

I imagine (because I haven’t played with cascades yet) opening a cascaded tiddler will not tell me, at first glance, what is going on (much like most of the example code/tiddlers at TW-com are hidden withing a macro forest and other chicanery).

This is akin to the design decision to implement the $list counter variable as counter=name-of-counter and not just say “there’s a counter variable called counter”. I thought you’d see that…

Anyway… moving on :slight_smile:

It is more per condition not per tiddler.

I was feeling this initialy but as I become more familular with it the main thing it achives is substantial control over all aspects of view/edit even whole of tiddler templates, without modifying any core tiddler.

To summarise

  • create a condition that if true names a tiddler title to replace a particular template element.
  • place above in a tiddler with the appropriate tag and set a list-before field to ensure its tested before the system defaults.
  • provide the replacement element tiddler for the above condition
    • this could be totaly new or a cloned and modified / customised existing core tiddler.

So although the overall picture is a little complex, the result is a plug and play extencibility safe and easy to use.

Always hide the bodies… :dagger:

1 Like