A Recommendation of Best Practice: Code-Body and Hide-Body

#1

There is a PR on GitHub and discussion here to add field code-body (set to yes) for some templates (e.g UI template for view/edit). I think we need to do this for all elements creating UI, macros, procedures, widgets, JS, etc.

@pmario started doing this for templates here fix #7579 PageTemplate/story can brick wiki by pmario · Pull Request #7583 · Jermolene/TiddlyWiki5 (github.com) and forunately the PR has been merged.

For readability, recursion in some cases, having cleaner/simpler to follow elements, I would like to suggest we need to do this for:

  • tiddlers contains macros/procedures which normally tagged with $:/tags/Macro and $:/tags/Global

    • a good programming style is to store only macros/procedures/functions in such tiddlers
    • this way the code is visible when you open a tiddler tagged with $:/tags/Macro or $:/tags/Global in story river

  • JavaScript modules

  • Mixed stylesheet tiddlers have not tagged with $:/tags/Stylesheet

    • The good news is stylesheet tiddlers tagged with $:/tags/Stylesheet now are shown as code and you do not see ugly core stylesheets specially those use datauri, or have mixed of wikitext/css.

please give your suggestions …

1 Like
#2

TiddlyWiki automatically hide body for some tiddler types, but some other needs to have the hide-body field.

For example

  • TiddlyWIki, shows a nice message instead of body when a font tiddler (like ttf/woff/oft/…) is displayed in story river
  • TiddlyWIki, shows a nice message instead of body when a zipped tiddler is displayed in story river
#3

@Mohammad in the past before the body cascade I took some time developing a solution I called show code and it automaticaly classified almost every tiddler appropriately and automaticaly invoked a hide body or show code view. I was supprised to see code-body introduced when it was because it is quite manual and not tiddlywiki at its best.

  • once you have a 95% accurate solution you then allow the hide-body and show code to be set either to no or yes.
  • this also suggests to me perhaps the use of new and existing type fields
  • which ever the approach adding information to the broad categories of tiddlers also allows for refined searches.
  • Personaly I often make use of an object-type field and a body cascade.
  • to me all core tiddlers should be addressed automaticaly or with settings so they do not need to be edited. If we are going to touch a large number of core tiddlers it would be better introducing a better approach.
#4

Thank you for your input! The cascades approach is a good solution to not manually add extra fields to tiddler.
By the way for portability, for example in plugins I add fields manually to control the rendering in story river.