[v5.3.2-pre] Technical Questions - Conditional Shortcut Syntax

[TW_Tones]

Please see this discussion I started Peeking at the pre-release 5.3.2 - Conditional Shortcut Syntax.

I have raised some technical Questions at the end I hope the developers can assist with;

• Would there be a way for us to reference the result of the filter to use in the content? answered below, use <<condition>>
  • The reason I ask is if the result of the filter was available in a variable it could be used in some cases to construct the result, allowing for interesting abraviated code opportunities?
  • Keep in mind the if/else/elsif structure could be inside a list, and handle a case structure for all listed tiddlers.
• Is there a way to use filters with multiple runs in them (Yes via a function?) but how about inline.
  • For example we may want the Ifcondition to be true if/:else/:else/:else eg one of 4 values.
  • Yet to test but could we just add quotes to the filter?
    • "[<test>match[one]] :else[<test>match[two]] :else[<test>match[three]]"
    • Then the “else” willl be used if <test> matches other values like “five six and seven”?

[TW_Tones]

@TW_Tones

Would there be a way for us to reference the result of the filter to use in the content?

For example a named variable such as filter-value

[CodaCoder]

So, like…

[<filter-value>count[]]

[CodaCoder]

More likely…

tv-filter-value

[TW_Tones]

Yes, count would be a simple example.

Or other versions like the filter transforms the value somehow, then tests the value for validity and inside the if/then/else displays the result, no need for a seperate variable.

With smart filters some quite sopisticated algorithiums could be developed with subsequnt filters using the output of previouse ones.

[jeremyruston]

@TW_Tones

Would there be a way for us to reference the result of the filter to use in the content?

Hi @TW_Tones this is covered in the docs. The second paragraph says:

Within an “if” or “elseif” clause, the variable condition contains the value of the first result of evaluating the filter condition.

[TW_Tones]

Thanks @jeremyruston I read it a few times, sorry. I thought it was “the condition” not a variable.

Now for some fun

[TW_Tones]

Jeremy I just tested this and the condition variable works inside the if but not the else;

Try this on the prerelease;

\function animals() elephant giraffe cow sheep +[format:titlelist[]join[ ]]

<$let animal=cow >

<% if [<animal>!subfilter<animals>] %>
	<<condition>> is completely unknown
<% else %>
  It is a(n) <<condition>>
<% endif %>

</$let>

The second reference to <<condition>> is blank.

[CodaCoder]

Good observation, Tones.

But going back to the docs, as Jeremy quoted them, else is not if or elseif. Plus, the result of your filter is blank. I think you’re going to need to provide a detectable result somehow.

One of the advantages of <$if> is that transcluded filters work, as do direct references to variables/fields. Plus, it provides a not attribute.

I’m a little concerned now that the new syntax may require a little more fancy footwork than I’d originally prepared for.

[TW_Tones]

If you look at the new structure you will note only if and elseif actually permit a filter, and they test a condition.

Jeremy suggested the result of the filter was available in the condition field, as I think you @CodaCoder have pointed out only, in the if statement, not in the else statement because the else is only blank when the condition is false.

This suggests a usage guidance;

• Else is “performed” only if the condition is empty,
• If you want to make the result of the condition available in subsequent steps (ie; condition can have more than one possible value) then you can make use of the <<condition>> variable only inside the if statement.

Now I will need to test the following;

• the ifelse condition result is available inside - correct
• Can I pass a value to a nested item?

To explore this further, notice here I use [true[]] and [!true[]] if true, the result is the current tiddler which is useful.

The ifelse condition result is available inside - correct

<% if [!true[]] %>
  a is <<condition>>
<% elseif [!true[]] %>
  b is <<condition>>
<% elseif [!true[]] %>
  c is <<condition>>
<% else %>
  d is "<<condition>>" thus condition false
<% endif %>

• Note “true” need not / should not, be define or a field.

I continue to explore but will add further content to the version in the Discussion Forum.

[CodaCoder]

Sorry, Tones, I don’t follow that block of code at all:

1. Why are you negating a non-existant filter op, true[] ?

2. two identical elseif clauses makes no sense. Even if the clause (test) was valid, once the first elseif succeeds, the rest of the block (all subsequent elseifs and any else clause) will be skipped.

3. What you have there, since the if clause is always false, is a way to ensure an else block succeeds.

@TW_Tones

Else is “performed” only if the condition is empty,

Perhaps. I’d prefer…

The first clause returning a non-empty result, succeeds. Failing that, the else clause, if present.

Also, I think you’re wrestling with scope with regards to <<condition>>. This variable exists throughout and within the clause that succeeds and nowhere… uh… else Which means…

1. all the way upto the closing `<% endif %> if there are no intervening clauses.
2. Otherwise, within the elseif clause that succeeds, if present

And I think <<condition>> might be a poor name-choice. I mean, it does represent the condition that succeeded, but it is not in itself a condition.

Still thinking…

EDIT: Dumb typo.

[TW_Tones]

I just used true[] and !true[] as conditions I manualy changed to explore the use of if else.

[TW_Tones]

@CodaCoder

Still thinking…

Looking forward to your further thoughts

@CodaCoder

And I think <<condition>> might be a poor name-choice

• This is as designed by the devs

Here is some research that illustrates sophisticated but simple to use functions to drive an %if clause;

\function object. Type() [get[object-type]]
\function tiddler.mode() [<tiddler-mode>!is[blank]] :else[{!!tiddler-mode}!is[blank]] :else[{$:config/tiddler-mode}!is[blank]] :else[[view]]
\function design.mode() [<design-mode>!is[blank]] :else[{!!design-mode}!is[blank]] :else[{$:config/design-mode}!is[blank]] :else[[no]]


<% if [tiddler.mode[]] %>
Tiddler mode = <<condition>><br>
<% endif %>

<% if [object.type[]] %>
Object type = <<condition>><br>
<% endif %>

• This is in my view superior to using the list widget, emptyMessage etc…
  • The question could be asked often “why are we listing one item”, when used as a condition

[CodaCoder]

@TW_Tones

@CodaCoder

And I think <<condition>> might be a poor name-choice

• This is as designed by the devs

Well, of course, duh. You say that as if it somehow negates my “why”, which you chose not to quote. As I went on to say:

@CodaCoder

I mean, it does represent the condition that succeeded, but it is not in itself a condition.

Please, in future, can we keep feedback intact? In my view, this is the best place for it – a bit too “chatty” for a GitHub post.

[TW_Tones]

I am not sure whats wrong here?

I did not disagree with you, nor negate your statement, I only clarified for any reader in the future. They may go looking for how I named the variable. If you want to challenge it, a reasonable case, perhaps visit github

If we consider your mention of it and my stating it is a dev issue, someone in the dev team may read and consider it. I am not responsible for addressing everyone else’s comments, but I did briefly. If this is important to you its up to you.

This thread was initiated by me to get answers, not give answers.

I am happy for you t0 raise this in this thread but I would urge you to manage the emphasis and importance you have for this, not expect me to.

Never the less “result” or “condition-result” may be a better variable name.