@linonetwo I think the problem you face is a conceptual one, One I faced as well some years ago. Perhaps somewhat like you, I was very familiar with procedural languages. You may be tempted to think the tiddlywiki platform is simply the extension of standard programming, it is not, and it can take a while to see the different approach.
- This may or may not help you.
The thing is tiddlywiki is primarily a rending machine. Whatever your TiddlyWiki script, in the end it is converted to html and displayed.
- You will see in a number of places it is said that macros (now Procedures) are a form of macro for which substitution takes place.
- The render process is in effect the last thing that happens.
A term I use to help me understand tiddlywiki is that part of the render process is to evaluate tiddlywiki script and replace it with the values etc… that it references, then convert it to html to render it.
However when we “program” we want to make use of intermediate values, that is we want to evaluate something to then use it for flow control, deeper logical constructs or as a step towards the final outcome. The thing is the wikitext or markdown, rendering is in someways there to generate a final result once it is displayed.
- There are plenty of ways this alternative approach gets hidden from us because of the versatility of variables, widgets and procedures. There are a few where it can confuse us with a programing background.
- However despite the challenge, it gives us interesting approach and platform on which to build solutions quickly and effectively with far less stuffing around especially with the “presentation layer”.
- Just to make it a little more complex tiddlywikis render process automatically responds to changes anywhere in the wiki, using a sophisticate set of trees I believe, in what they call a fake DOM. This often has the effect of rendering and re-rendering only the parts of the wiki related to any changes. To us programmers it gives a false impression that it is not a rendering engine.
- Recent developments go a long way to bridging this gap and they are functions, filtered transclusions and the back tick attributes, because they do “evaluate” filters and attributes before invoking the procedure or widget that uses them.
- The most clumsy version of this is the wikify widget, If you learn to do without it, life gets easier.
- Like any widget consider that what is inside the widget ultimately will be displayed, and the widget can not itself become the input to another widget.
Feel free to ask further questions.
I will give a direct responce to your examples later, as I have an appointment now.
Note: your \define ariaLabel() <<lingo Refresh/Label>>
returns empty for me <<ariaLabel>>