Conditional Operators in TW 5.1.20

[Mohammad]

While there were alot of request for simple conditional operations, it seems the new TW 5.1.20 has this great feature

See

• https://tiddlywiki.com/prerelease/#Conditional%20Operators

I think this needs to be discussed and examples are needed for clrification!

So, interested people, please give their use cases questions here!

-Mohammad

[TonyM]

Mohammad

This structure will return true only if the input is true, any other value including empty  will return false

<$set name=input value="true">
<$list filter="[<input>match[true]else[false]]" variable=returned>

</$list>
<$set>

Thus inside the list you can test

   <$list filter="[<returned>match[true]]">

   </$list>
   <$list filter="[<returned>match[false]]">

   </$list>

Regards

Tony

[TonyM]

Observation

~[[false]]

or else false

Is equivalent to else[false] in some circumstances, but it can be placed within a single run.

Retards

Tony


On Sunday, 4 August 2019 00:06:14 UTC+10, Mohammad wrote:

[Mohammad]

This is great!

Still we have not real branching with then-else

but we have

if NonEmpty

  return then part

else

 return else part

end

And we need a construct like you proposed!

--Mohammad

[TonyM]

Mohammad,

Can you clarify what you mean by branching?

Despite my investigating replacements for common structures in procedural programing languages, Tiddlywiki is not actually procedural. Even when you trigger a "batch" operation control is returned only once it is completed and everything visible is re-rendered.

The final result is presented each time the tiddler is rendered into HTML. this is very common for online solutions as was for old mainframe apps. Basically it is as if the server  processed everything its given and returns the result. The browser then sits there doing nothing, while the browser (client) lets you interact with what is in your browser and at the end you "send", the changes get sent back to the server for processing. In tiddlywikis case, the only browser to server interaction need be the save and re/load process. But A similar model is used within tiddlywiki and our browser session. When we save a tiddler, or navigate or use another trigger like a button or action this is sent to the tiddlywiki internals they are processed to completion and the result returned and the wiki re-rendered for our pleasure. One of tiddlywikis strengths is it does this efficiently and re-renders only that which has changed as a result of your change.

Because of this architecture we need our designs to "finish", they do not branch off or spawn additional processes like a normal procedural language. There must be a technical term for this. 

Now I know this view is not 100% correct but it helps me visualise the "platform". Perhaps it always needs to be complete (related https://simple.wikipedia.org/wiki/Turing_complete)

Rather than branching I think in tiddlywiki we are more likely to "nest" things. We can selectively nest different things in other things. Our wiki text is nested inside a tiddler and the tiddler inside the story and the story in the browser window (page template) and when a Change occurs all these nested structures are economically processed and re-rendered the full nested result presented.

Regards

Tony

[Jeremy Ruston]

Hi Tony

Your description is very nicely put.

The curious thing for me about both the filter language and wikitext is that they both evolved from very simple initial conditions:

* The filter language evolved from the idea a simple list should be a valid filter, evaluating to the titles in the list. Given the double square bracket quoting that we already had, squeezing the operators in between the opening double square brackets allowed us to add logic without taking users too far from the existing logic (“square brackets are special”)

* The wikitext language evolved from binding together two parents: the wikitext syntax established with TWC and the HTML syntax for elements

Both have now become rich and expressive languages by iterative evolution from those initial ideas.

(A sore point in the design is action strings: we re-use the widget syntax, but at best its a declarative representation of procedural logic).

Best wishes

Jeremy

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/14de1ca9-88ae-42ce-b729-0d3ba15eeae8%40googlegroups.com.

[Mohammad]

Thank you all for these descriptive replies!

By the way branching here means decision making and executing part of code based on that! Sخ $list with emptyMessage has a simple branching logic!

--Mohammad

On Sunday, August 4, 2019 at 1:57:48 PM UTC+4:30, Jeremy Ruston wrote:

Hi Tony

Your description is very nicely put.

The curious thing for me about both the filter language and wikitext is that they both evolved from very simple initial conditions:

* The filter language evolved from the idea a simple list should be a valid filter, evaluating to the titles in the list. Given the double square bracket quoting that we already had, squeezing the operators in between the opening double square brackets allowed us to add logic without taking users too far from the existing logic (“square brackets are special”)

* The wikitext language evolved from binding together two parents: the wikitext syntax established with TWC and the HTML syntax for elements

Both have now become rich and expressive languages by iterative evolution from those initial ideas.

(A sore point in the design is action strings: we re-use the widget syntax, but at best its a declarative representation of procedural logic).

Best wishes

Jeremy

To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.

[TonyM]

Mohammad

So with that clarification, I would suggest the methods in the case example I gave addresses many.

Most branching is about selective display and nesting.

Are you looking for something else?

Regards tony

[Mohammad]

Thanks Tony! That's quite true!

Also,

 This if-then-else gives a huge flexibility! One example

<$list filter="[<__template__>match[default]then[$:/plugins/kookma/timelines/templates/gilan]else[$template$]]" variable=templateTiddler>
<$tiddler tiddler=<<currentTiddler>> >
<$transclude tiddler=<<templateTiddler>> mode=block/>
</$tiddler>
</$list>

The above code uses a default template when user has not sent any template and uses the user supplied one if he/she has sent a template!

This is part of my under development plugin named: timelines

I really appreciate this fruitful thread and discussion!

Cheers

Mohammad

[TonyM]

Jeremy,

Tiddlywiki is rich and wonderful now. It took me time to jump to tw5 from twc.

This history help explains to me a little of why this transition was difficult for me and where I perceive limitations.

Given the context of this thread, perhaps I can express a hard to express idea.

Html is still quite usable in tw5 but as you know actions need to be mediated through widgets and I understand why. However there is a rich source of content and methods in html5 we cant make use of because of this. I do ask myself if a few widgets, kind of widget primitives, could open more html to us, html that depends on simple JavaScript functions, For example a way to replace the onclick function, some ways to capture values resulting from html.

The idea is to perhaps enable the functionality available in html5 back into tw5 rather than the needs found in the gaps, driving new widgets into tiddlywiki. I have some understanding of the difficulties but since I am not expert in either html or javascript I find it hard to survey both to determine if this were possible.

For example could tiddlywiki respond to html submits and store the result? Accept the detail in a form into a tiddler and its fields. Since we can do the reverse.

No need to respond, just food for thought.

Regards
Tony

[TonyM]

Mohammad,

[edited]

Give this example of yours I currently use another pattern for something similar. So I thought It a good time to share.

\define display(template)
<$set name=template value="$template$" emptyValue="$:/plugins/kookma/timelines/templates/gilan">

<$transclude tiddler=<<templateTiddler>> mode=block/>

</$set>
\end

Not tested

Some points

• Use emptyValue to set the value of a variable for which no parameter was supplied
• See how I use the same name as the parameter when making the variable

I am still at a lost to know how to do the equivalent of the following with the transclude widget

{{tiddlername}}
Vs
{{||tiddlername}}

Other ideas

• I almost always write my macros to operate on <<currentTiddler>> so they are more reusable.
• I like an idea I think you suggested to pass as a parameter a macro name you then execute
• 
  

I also like to develop macros that you pass a filter to, code snipit;

\define display(filter)
<$set name=filter value="$filter$" emptyValue="a default filter">
<$set name=input value={{{ $filter$ }}} emptyValue="a default">

<$list filter=<<filter>>  variable=null>

....

</$list>

<$transclude tiddler=<<templateTiddler>> mode=block/>

</$set></$set>
\end
<<display"afilter">>

Once again this makes such macros much more reusable.

• Use with variable=null because you do not need it and the containing tiddler remains the currentTiddler

Regards

Tony

[Mohammad]

Tony!

On Sunday, August 4, 2019 at 5:18:44 PM UTC+4:30, TonyM wrote:

Mohammad,

Give this example of yours I currently use another pattern for something similar. So I thought It a good time to share.

\define display(template)
<$set name=template value="$template$" emptyValue="$:/plugins/kookma/timelines/templates/gilan" variable=null>

<$transclude tiddler=<<templateTiddler>> mode=block/>

</$set>
\end

Not tested

The above code is more readable and maintainable! emptyValue is quite clear that template parameter has not been passed! So, I think this is more semantic than the one I proposed through list!

Some points

• Use emptyValue to set the value of a variable for which no parameter was supplied
• See how I use the same name as the parameter when making the variable

• Use with variable=null because you do not need it and the containing tiddler remains the currentTiddler

I am still at a lost to know how to do the equivalent of the following with the transclude widget

{{tiddlername}}
Vs
{{||tiddlername}}

Other ideas

• I almost always write my macros to operate on <<currentTiddler>> so they are more reusable.
• I like an idea I think you suggested to pass as a parameter a macro name you then execute

I also like to develop macros that you pass a filter to, code snipit;

\define display(filter)
<$set name=filter value="$filter$" emptyValue="a default filter">
<$set name=input value={{{ $filter$ }}} emptyValue="a default">

<$list filter=<<filter>> ....

</$list>

<$transclude tiddler=<<templateTiddler>> mode=block/>

</$set></$set>
\end
<<display"afilter">>

Once again this makes such macros much more reusable.

Regards

[Jeremy Ruston]

Hi Tony

> Html is still quite usable in tw5 but as you know actions need to be mediated through widgets and I understand why. However there is a rich source of content and methods in html5 we cant make use of because of this. I do ask myself if a few widgets, kind of widget primitives, could open more html to us, html that depends on simple JavaScript functions, For example a way to replace the onclick function, some ways to capture values resulting from html.
>
> The idea is to perhaps enable the functionality available in html5 back into tw5 rather than the needs found in the gaps, driving new widgets into tiddlywiki. I have some understanding of the difficulties but since I am not expert in either html or javascript I find it hard to survey both to determine if this were possible.

I can understand why you’re asking, but sadly I don’t think there’s a good answer. The assumptions made by DOM-based JS apps cannot be supported in an environment like TW5.

One of the validations for the design of TW5 is actually React: it was invented long after TW5 was released, but it embodies exactly the same principles for updating the display in response to changes in a data store. And you find the same thing: off-the-shelf JQuery libraries are not compatible with React. At best they can be wrapped, at worst they need to be rewritten.

> For example could tiddlywiki respond to html submits and store the result? Accept the detail in a form into a tiddler and its fields. Since we can do the reverse.

We can already present a form and store the results in a tiddler when a button is pressed. We can’t do it using HTML primitives without some form of data binding, which is pretty much the raison d’etre of TW5 (and React).

Best wishes

Jeremy

> No need to respond, just food for thought.
>
> Regards
> Tony
>

> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f149d1d3-c6a8-4359-9899-9dc2bbf7b43a%40googlegroups.com.