There is a way to use the $list widget to emulate an if-then-else construction and it is working perfectly. But this is not explicit and this is especially a problem I have encountered when learning TW: how in hell could I code a conditional block?
Why not add a $if widget? Like:
<$if condition=[myfilter]>
<$then>
...
</$then>
<$else>
...
</$else>
</$if>
with $then tags optional
Once you’ve used it for awhile, it will seem explicit. Enough.
You can use the Reveal Widget for syntax that looks more like if/then.
There’s a third-party plugin by Evan Balster for $if, $else, and $else-if widgets that can be used with filters. The original demo site doesn’t seem to exist any longer, but I found a copy on another of his wikis.
It’s not actively updated, but I’ve used it extensively on every wiki I’ve made in the last ~2 years, and I’ve never had issues with it.
My point is it would help new users to learn TW faster than I did.
And still, I would prefer a crystal clear syntax with $if-$then-$else (and $elif) for conditional blocks and $list for… lists.
Hi @TartakOO there is some discussion of that approach on GitHub. In principle I like the idea of a more idiomatic way of handling if/then/else but I have reservations about implementing it as a widget. Our general policy is that we aim for widgets to be small, composable primitives, and work in the wikitext layer to optimise for expressiveness and brevity.
Implementing if/then/else at the wikitext layer might best be done with a different syntax for block mode vs. inline. For block mode we might use the backslash syntax that we use for pragmas:
\if [<currentTiddler>match[HelloThere]]
Displayed if the filter returns at least one result
\else
Displayed if the filter returns no results
\endif
I don’t have a good suggestion for inline mode. For the sake of argument, we could have (if( FILTER ) then ( TEXT ) else ( TEXT )). It’s obviously unwieldy and alien but it shows the required approach: to choose unique character sequences to start, delimit and end the filter and the clauses:
My name is (if( [<currentTiddler>match[HelloThere]] ) then ( TiddlyWiki ) else ( anonymous ))>.
Adding more constructs, more ways of doing things, more things to learn, complicates the documentation and the documentation process, complicates communications, makes core maintenance more challenging.
Just because something could be done: careful what one wishes for.
Bad idea for too many reasons.
Yes, too me the $list widget and its filter is far more powerful than if/then/else constructs although I know in earlier days I wanted to find ways to represent if/then/else in my code.
@TartakOO my I suggest keeping this desire in mind, once we have the 5.3.x releases there will be new options to define and redefine widgets to test out alternative code patterns and the most successful may rise to the top and they can be added to plugins, core Plugins and perhaps one day the core.
Thanks to all, this is enlighting for me.
@jeremyruston: pragmas would do the job too; the block versus inline mode seems an important matter here but I don’t understand yet why this have to be a different syntax.
@TW_Tones I can’t wait to put my hands on 5.3 features, this looks very promising.
Keep in mind they are quite extensive and primarily driven by the core developers. I expect there will need to be a “long tail” of users contributing to the documentation and examples before most users will be in a position to make use of them.