The following code works (whew…after a long day’s trying complex IF THEN ELSE conditions). However, I assume there are better ways of coding the logic. I am concerned that by simplifying each condition through many repeated $list widgets, when the numbers of tiddlers increase in the wiki, performance will decrease, especially as this procedure is in a viewtemplate for many tiddler types. It is easily understandable and that is a plus for future tech support.
I’d be interested in seeing others’ coding suggestions/improvements.
NB. the display of labels in each $list condition and the List-Links macro output are purely for debugging and will be removed
So to be clear you are using the caption field as a defacto tiddler type. Perhaps it is best to use another field and leave the capotion free to be unique if required?
I can write it using the %if as a more performant structure if you want?
Ok I see the caption only uses the prefix to divide tiddlers.
I just did three to illustrate, untested. this is a “case structure” which only asks as many questions as it must, but all these questions could be asked inside a filter if you use the 2nd approach below.
However further optimisation could;
make a macro for the content of each
or a list widget could itterate “History [[local History]] Gallery etc…” and everyting displayed through a macro.
Thanks guys. I was playing with nested if then else structures but found they were very unstable. Unless the operator started in char 1 of a line, it might not be recognised and in the end I got so confused with the logic, I gave them away and started with a clean sheet of paper to write down the login. That’s why I ended up with multiple $list widgets and recognised there might be a more consise way of stating things.
I think your <$list is perfectly fine for the beginning. Especially if you are still developing it. Once the stuff has stabilised it may be possible to create a procedure that does create the lists dynamically, to have less duplicated code.
The performance will be very similar for “linear duplicated code” or “dynamic” code. Only dynamic code will be more fragile if you need new parameters or special handling for exceptions.
Your list filters should not be that expensive, since most of them start with one tiddler <currentTiddler>. The only expensive one is the backlinks[] filter, which is only used once.
Thanks again everybody, your thoughts are revealing (in a good way )
I have, for now, adopted a mixture of @TW_Tones and @CodaCoder suggestion and implemented a ‘case’ structure. Following @pmario’s suggestion about keeping it simple when creating and review once working, I will keep the multi-filter conditions for each tiddler type I am looking for and review once tiddler types have been settled.