With this code, only the first %elseif is processed despite the nomenclature field being empty. If I replace nomenclature for ‘common’ or ‘abbreviated’, the correct value is returned but only via the first %elseif.
As an aside, can someone provide an example of how to use the $list statements alternative facility to achieve the same result. I can’t work that out either. I believe that the $list can return an alternative if it returns an empty list, but can this alternative in itself be another $list etc…
@Bob_Jansen it is a reasonable guess but wrong that you are not closing every if and elseif with an endif. try adding 4 more <%endif%>'s after you last one and please report back.
In some ways you are using if conditions to replicate a “select structure” but under the rules of the if structure you must close them in this case even if they seem redundant.
We could build a select structure that does not need this but since it can be implemented with the if structure it is somewhat redundant.
FYI: As @pmario said only a filter run is valid in if and endif’s and the result is true if not null, and the value returned is available inside the if or endif in the variable <<condition>> and no where else as it is nul
However, one advantage of conditional syntax is that the result of each %if/%elseif filter is available under that filter as the variable <<condition>>. Furthermore, get returns only non-blank field values, so get[nomenclature] will automatically fail whenever has[nomenclature] is untrue.
We can take advantage of these two facts to further simplify your code:
And since this highlights some repetitive code, we could even take it a step further and store the “content” snippets as procedures, defined at the top of this tiddler:
Yes. Conditional shortcut syntax is one of the few TW constructions that doesn’t use paired tags/brackets: you do need one <%endif%> per <%if ... %>, but you can have as many intervening<%elseif ... %> statements as you like (and one final <%else%>).
Notice that I’m using the variable= attribute of each $list to assign an alternate name to the variable used to store each $list result. If I’d skipped this necessary step, each $list result would instead be assigned to the <<currentTiddler>> variable, and any nested instances of <<currentTiddler>> (or transcluded fields like {{!!State}} would lose their original values.
Although, under the hood, the conditional syntax is just a shortcut for this sort of nested $list, we don’t need to worry about preserving the original value of <<currentTiddler>> in a conditional: it automatically assigns any filter output to variable="condition".
Since your elseif steps all use a similar template for their output, we could somewhat reduce the number of $list widgets required by bundling all the get[...] steps into the same filter:
If none of the above filter runs produces a result, the $list falls back to the final $list-empty…
<$list-empty>
<<unknown-type>>
</$list-empty>
But (if it’s not already clear), I really don’t recommend using nested $lists for this sort of use-case; it’s a perfect candidate for the much simpler conditional syntax.
<%if [{$:/info/url/protocol}match[file:]] %>
Loaded from a file URI
<%elseif [{$:/info/url/protocol}match[https:]] %>
Loaded from an HTTPS URI
<%elseif [{$:/info/url/protocol}match[http:]] %>
Loaded from an HTTP URI
<%else%>
Loaded from an unknown protocol
<%endif%>
@pmario , your suggestion of the multiple {{{ }}} applies only to the test condition. If I change the statement to
I think this one is important. Can you see, how much easier to tread the whole thing is. And additionally it’s also easier to test. Every component, like the <<known-type>> can be tested on their own.
So if something goes wrong, you only need to test the elements that you changed, and not those where you already know that they work
@pmario , yes I do indeed see how simpler it reads.
I have learned that my problem is that TW programming requires different way of thinking from ‘normal’ programming and I don’t do it often enough for the lesson to be retained. My project requires me to do TW programming and ‘normal’ programming and my brain finds it difficult to switch between both. I am used to normal programming, have done so for the past 50 years or so.
On top of all this, I am also working as my wife’s business manager and currently we are working on a major retrospective exhibition at a Sydney university, a major article in one of Australia’s foremost arts magazines and another exhibition at a Sydney gallery later this year. I have only so much space to keep it all together.
So I hope you can see why I post as many queries as I do. What you can’t see is the knowledge that is being passed through your answers. The lessons learned through the example answers provided all go in to my ‘useful stuff’ wiki which is growing daily.
Without this group, I would not be able to program TW as I do now and certainly the effort and time provided by this group is beyond anything I have experienced before.
I’ve said this before and others have also. The examples in the documentation are by and large not useful and certainly do little to provide assistance in addressing real world problems. They are good for people like yourself who just need a quick reminder, oh yeah that’s how to do it. GROK is useful as are the various pages of info I have found. It’s a pity this can not be addressed.
I feel the main area that needs work is filters with real world examples. Have a look at the Xojo Documentation ( Using the Xojo Language — Xojo documentation ). When you get into the nitty gritty it has real working examples, snippets of code you can cut and paste into your project and use as a starting point. Now I can already hear the shouting, but that takes a lot of time to prepare and keep up to date. Maybe it does but without such resources, TW will find it hard to become mainstream and beginners to TW like myself will continue to experience frustration.
I for one are happy to keep helping you Bob and through that learn how best to support others and eventually improve the documentation, but as you may guess I have my own journey to understand the possibilities and best choices with the changes in 5.4.0 Lets eat the elephant a bite at a time.
Yea, that’s the tricky part. Advanced TW wikitext can be seen as a programming language, but IMO it is not.
It’s more like a text templating machine, similar to handlebars, without the need to know JavaScript to use it.
All our parameters are “strings” in and “strings” out. That’s also true for eg: \procedures. They are not really executed, when they are placed <<called>>. There text is substituted to the position you place the call.
Cool
No problem. This forum is here to ask questions. Similar questions in a different contexts,
reminds me that we have a lot of room to improve the TW documentation.
I do agree. It can be addressed, but as you wrote, there are many hats to wear. A day only has 24 hours, and we have to sleep at night - sometimes
You are right. With TestCaseTiddlers and CompundTiddlers we now have the possibility to show new functionality in “isolated” tests, where users can experiment with them, without breaking something.
The “test tiddlers” do not pollute the main TW reference documentation anymore.
That was not possible in the past. IMO that’s one of the main reasons, why TW syntax and especially filter syntax documentation is as “sparse” as it is at the moment.
The other reason is. To show the basic functionality of an eg: filter, the examples have to be simple. If they are too complex, users do not read them.
But imo “real world examples”, most of the time are complex.
Users want solutions for their complex problems, without reading and experimenting with the “simple” examples we present. So they do not read them. … We are back at square one.
GROK goes from “simple” to complex. But it’s a lot to read. That’s more time needed, as many users want to invest. …
That’s right. But we need to be aware, that it’s spare time, that is used to create the docs.
IMO it needs more financial incentive to contribute, interesting to read, tested and working examples, that are not entirely AI created. Because most of the filters they create, still do not work. (Probably because of missing docs they can “borrow”)
Yea, from time to time our filter syntax can be frustrating.
There are ideas and prototypes on the way to improve automatic filter explanation.
