Agreed but also recent 5.3.x improvments, we are a long way from exploring the posibilities functions, custom widgets and parameters widget all play a role here.
I don’t see how functions might “play a role here”.
Yes, my example is look-like a switch case, but it is a basic example.
I think I should have highlighted this
Then it will be easier to make mistakes, IMHO. I think adding a wrapper to the conditional statements simplify the syntax and avoid the $then.
Any condition test can make use of functions and custom operators and in some ways “cases and if” are all about conditions. I am still researching the posibilities but functions help a lot.
- I can illustrate this later
would it break existing wikis using the plugin if <$if/> was renamed (like to <$cond/> or something) but <$then/> and <$else/> stayed the same? if the plugin only looks at then/else widgets inside of “if”, then we could keep the most obvious names for most of them and just change the parent.
to address the main point, i haven’t used the plugin as i did not know about it but simple if/else is much easier to work with than the complex reveal widget, which often needs multiple nested reveals to get the job done (and an “elseif” would add functionality the reveal widget doesn’t have, right?)
1 Like
I think what you’re proposing is what I said here. And to be clear, there is no $then in Evan’s condition plugin.
It doesn’t. The plugin supports this effective grammar:
<$if ...>
</$if><$else>
</$else>
There’s also an $else-if, but again, it’s not nested inside the $if.
Also $else can be used right after other conditionals…
1 Like
I think that the incompatibility with Evan’s Conditional Plugin means that a core <$if> widget is a non-starter. We have to a take a broad view of backwards compatibility and it is not acceptable to knowingly break a popular plugin.
I have made a PR for an alternative approach here (see Conditional Shortcut Syntax by Jermolene · Pull Request #7710 · Jermolene/TiddlyWiki5 · GitHub). Instead of using the widget syntax, it introduces a completely new shortcut syntax that is as easy to type as possible:
\procedure test(animal)
{% if [<animal>match[Elephant]] %}
It is an elephant
{% else %}
{% if [<animal>match[Giraffe]] %}
It is a giraffe
{% else %}
It is completely unknown
{% endif %}
{% endif %}
\end
<<test "Giraffe">>
<<test "Elephant">>
<<test "Antelope">>
There is a preview of the PR to try out here.
3 Likes
As I wrote in GitHub, I believe If/then/else widgets developed by Robin follow the same philosophy and syntax of TiddlyWiki widgets! So, why not use Robin implementation?
It is not a good reason to stop a core feature development because there is a rather old plugin. We should always stick to the core and core backward compatibility as TW development policy!
We know some of good Tobias Beer codes/plugins are now part of the core.
Also the Evan condition widget is developed based on older concept. and is similar to $reveal.
I myself always stick to TiddlyWiki core features and when I can use a core feature, I use it, not third party one. So, I am highly in favor of Robin development.
See Robin latest efforts here:
1 Like
Would you give an example from TiddlyWiki scripting syntax using something like not?
TiddlyWiki uses ! for not , e.g. [tag[Test]] and not [!tag[Test]].
This is not a TW compatible syntax: <$if not value={{$:/StoryList}}>.
Have you tried Robin development of $if widget? Please take a look. It is here https://tiddlywiki5-r79sfdnqv-jermolene.vercel.app/ with full documentation and examples. It is clear, concise and very easy to learn, as it follows closely the TiddlyWiki widgets syntax.
Your fear may go away or you may find solution to convert your code using core feature if for any reason you have to upgrade to TW 5.3.2+.
<!-- if my-var contains 0, "", [empty list] or blank... i.e. "falsy" -->
<$if not value=<<my-var>>>
<do-something>>
</$if>
That’s filter syntax.
In wikitext HTML, not is being treated as an HTML boolean attribute like, for example, readonly in regular HTML.
What do you mean? The syntax perfectly is fine. Although, checking the (negated) value of the $Storylist text field is always false (in a normal Tiddlywiki, anyway). This might be more useful:
<!-- if story is empty, display something cool... -->
<$if not value={{$:/StoryList!!list}}>
<display-cool-stuff>>
</$if>
It’s not that I find Robin’s approach logistically complicated or difficult to use - as I said, I would have been very happy to use it instead of Evan’s plugin if it had been available a couple of years ago. It’s just that, since it was not available back then, I’ve already incorporated Evan’s $if widget in hundreds of places across hundreds of template tiddlers (and multiple wikis), and having to convert all that just so that my wikis would function the same way they do now would be a major barrier to my adoption of future TW versions.
I know that it’s possible to accomplish similar effects with $list (which I also often use - often in conjunction with Evan’s $else). $reveal feels verbose and clumsy by comparison; I’ve avoided it since I first discovered Evan’s plugin as a concise alternative.
Indeed. The semantics are wrong (for this purpose). Were they not, @jeremyruston would not be considering any proposals for improvement in this area.
That is right! $list can be used instead of $reveal. I think Evan’s $if somehow tried to address users need for several clumsy $reveal widgets.
I myself always used $list for decision making and rarely $reveal. Filters allow to make decision based on simply or complex filters. I used this methodology for if/then/else-if/else in TiddlyWiki. Note that condition can be a simple or complex several steps/runs filter.
<$list filter="[<cond...>then[true]else[false]]" variable=something>
<$list filter="[<something>match[true]]">
TRUE BLOCK
</$list>
<$list filter="[<something>match[false]]">
FALSE BLOCK
</$list>
</$list>
You may use shorten structure when you need only a simple if construct, or you need simple else (here you use can emptyMessage with attribute). The whole structure can be wrapped in a macro so prevent you from extra typing! Or you may use macros for false/true parts and just type one $list with emptyMessage if you need if/then/else.
Yes, and most decision making in TW is based on filters. Widgets and Filter are the heart of TiddlyWiki.
That is another thing! They are used normally for on/off state like disabled/required. They are not used for conditional statement. Here we are talking about if/then/else construct, so we need to write conditional statements. In TW these statements are filters. The $reveal is an exception, which most user with the current state of TW avoid using it where possible.
I mean this syntax which is used in Evan’s plugin is not a TiddlyWiki compatible syntax.
Look at this example from Formulas for TiddlyWiki — spreadsheet-inspired number crunching (chronicles.wiki)
<$if value={{!!animal}} match=cat> Meow! </$if>
<$else-if value={{!!animal}} match=dog> Bark! </$else-if>
<$else-if value={{!!animal}} match=bird> Tweet! </$else-if>
<$else> This isn't like any animal you've seen before. </$else>
This is very confusing! the <$else-if> is a separate widget it is not inside the first $if, but it is part of that $if widget.
Add a line break between them
<$if value={{!!animal}} match=cat> Meow! </$if>
<$else-if value={{!!animal}} match=dog> Bark! </$else-if>
<$else-if value={{!!animal}} match=bird> Tweet! </$else-if>
<$else> This isn't like any animal you've seen before. </$else>
It returns error. Why?
How do you teach this syntax to new learners?
I think TiddlyWiki in 5.3.1 is very powerful in comparison to TW 5.1.x (where condition plugin is developed). It worth to have its own simple to follow if construct. Many users prefer to use core features. There no need to always update to latest TW, so TW with condition plugin can work as before and we can support Robin efforts for $if in core.
1 Like
This is not my reason for objecting to a core if widget, it is because although useful I think we can design a more comprehensive solution. To maintain backwards compatibility putting a widget in the core is adopting it as proposed indefinitely. I do appreciate @rmunn’s efforts, and I think Robin raises this to an importance level it deserves; However I think it needs more and longer development times nif we are to put an $if in the core and documentation, especially since the release of 5.3.x offers so many possibilities. For example here is my custom widget for if then else with an example;
This works now
\widget $if.then()
<$parameters filter="[all[current]]" $params=all-params>
<$list filter=<<filter>> variable=slot>
<$slot $name=<<slot>>/>
</$list>
</$parameters>
\end $if. Then
<$if.then filter="[all[current]has[switch]then[then]] ~[[else]]">
<$fill $name=then>then result</$fill>
<$fill $name=else>else result</$fill>
</$if.then>
- It is an idea like one we @Mohammad shared back in the day with calling named macros.
- In the above you define the then and else code in fill widgets
But using this approach it can be simplified to a case statement
This works now
\widget $if.case()
<$parameters filter="[all[current]get[case[]]" $params=all-params>
<$list filter=<<filter>> variable=slot>
<$slot $name=<<slot>>/>
</$list>
</$parameters>
\end $if.case
- Just set the filter result so the condition results in a named case with a matching fill widget when calling.
Offline I have not only written code that uses the fill widgets but conditionally
- calls a procedure,
- a widget
- and transude tiddler content.
- I also forsee a widget which can use the contents of arbitrary html tags to find the content for each condition.
the $if widget does not propose a way to do this versatile set of conditional outcomes but proscribes a particular way and set of outcomes. This is too restricted in my view to use a valuable widget name $if.
I am yet to test @jeremyruston’s approach but to me this avoids the compromises of adding a core widget and has little impact elsewhere. I hazard a guess we can use it to also call procedures, use fill/slots, transclude etc… as well.
@jeremyruston My only questions so far would be;
- Can we choose if the result is inline or block modes?
- Ideally without introducing first blank lines
- Can we use the result as a value to an attribute?
- With or without wikification
- Could we make this valid within wikitext not just procedures?
I love this community.
2 Likes
The new parser options Jeremy proposed in draft PR 7710 internally creates list widgets. They can be tested with the draft preview Edition.
If you switch the edit-preview to “parse-tree” or “widget-tree” you can see what’s created internally
Click to show the image
Code
\whitespace trim
\define animal() ElephantX
{% if [<animal>match[Elephant]] %}
It is an elephant
{% else %}
It is unknown
{% endif %}
The advantage is, that the existing list-widget can be reused and the refresh mechanism is highly optimized already.
The disadvantage is, that it introduces a completely new syntax {% if %} wich is very similar to existing templating engines Jinja or NunJucks.
I do not know if that’s a coincidence or if ideas are borrowed from them.
Hi Tony
Thank you for your input, specially the custom widget for if/then/else.
I follow your other threads on development of custom widgets using TW 5.3.1. They are really helpful and speed up onboarding with 5.3.1
Like you for if/then/else I think we should consider new features in 5.3.1.
My only concern is consistency and logical adherence of all parts of TW scripting.
1 Like
Please. I know what we’re talking about here – I opened the thread. The point of the thread, which I opened in Developers, is to ask a developer of a proposal to make my (and others) editing job easier should the proposal come to fruition.
What this thread ISN’T about is debating the merits of any given plugin – especially when a particular plugin is earmarked for obsoletion, if not flat-out removal. It’s completely fine if you don’t like it. You’re welcome to hold your own opinion, however right or wrong you may be – it’s not a matter of debate here. What this thread IS about is the position some of us find ourselves in because of decisions we made in good faith, years ago and asking that our task moving forward might be eased by making some changes to said proposal. ← There’s no debating that at all – we are where we are, sadly.
You’re not in that position. Good for you. If you have an answer to the problem intimated in the OP, I would be glad to hear it.
1 Like