A Dynamic Filter is a filter created at run time (render time) and is not hard coded into the WikiText (script).
A Static Filter is a filter known at the scripting time and is hard coded into the WikiText (script).
Example
This example uses a static filter and lists all tiddlers tagged with HelloThere
<$list filter="[tag[HelloThere]]">
...
...
Below example shows a simple dynamic filter. It selects the correct filter based on a user input. For demonstration purpose and simplicity I used a macro here:
This example gets the user input if it is equal to 1 , then it lists note tiddlers using noteFilter, in all other cases it lists journal tiddlers using journalFilter.
Questions
I wish to know what is the best practice here to dynamically set a filter based on some conditions?
I started writing this but then realized it uses a custom filter run prefix that I am used to, pressed for time at the moment but you could try to adapt the same pattern with core code:
It really depends on the exact use case and how often the filter will change between noteFilter and journalFilter.
If the filter will change between the two often but some list items might be in common, the following would be faster in terms of refresh performance:
Thank you Saq, reading your codes gives a lot of ideas!
Your pattern above shows me I can ignore $set and directly make decision in filter expression in $list filter attribute (where I use the selected filter).
@Mohammad I will respond to this challenge, however it is also a simple example to illustrate my argument that there is no problem using nested filters and it offers additional features, for example;
The point being you can access intermediate values and use them in your solution, which is something you can’t do when building single filter solutions.
I expect the solution is going to be almost as efficient, possibly more so as the same work needs to be done, its just hidden in a single filter.
Back to the challenge;
The first thing I see is you generate a list of titles [tag[$:/tags/MyFilters]] then for each of these you extract a field value !!tid-filter (which implied currentTiddler then use this as a filter.
This means we want to use two different “currentTiddlers”
I will return with a fuller answer, However when I have this kind of problem I go lookig for operators using <<..currentTiddler>> - the input title
…currentTiddler - the value of the variable currentTiddler outside the filter run.
It really depends on the context of what you are trying to do as to whether there is a benefit in trying to use a single filter expression or what a good code pattern might be. If you want to use the list of results for further processing or as input somewhere else, then yes absolutely a single filter expression is desirable where possible.
Off the top of my head you could try something along these lines:
Yes, that is the usecase! I am working with some complex template! A script determine what template shall be used based on criteria comes for current tiddler, and then I need to do further computation.
One another real case is Mehregan Smart tab! When there are several smart tabs, and I want to show a notification bubble next to tab title indicating the tab is has any contents or not!
Thank you Tony! I am 100% with you!
In my case I have to pass the results to other widgets to do further processing in a complex code! So I need to keep the code simple and maintainable and remove extra parts!
But for other cases your pattern is more clear, and flexible.
Acknowledged.
Would you mind sharing your then filter run prefix code? There have been a few instances where I wished for such a thing, but had to go a more convoluted way, as it doesn’t exist in the core.
It is at the top of my TW to do list to publish a plugin consisting of my custom filters as soon as the time allows, which hopefully should be later this month.