An approach for a dynamic filter

#1

NOTE: Many members of this community often disagree with my “UNORTHODOX” approach to doing things. Everything I share is only meant as fun insights into TW behaviour and types of fun things that can be done with TW.

I have a cognitive disability and bad eyesight (Fuchs Dystrophy). So please pay no mind to the many little, surely very odd to you, tricks I use to compensate.

EDIT: The purpose of this post is to demonstrate a possible approach to dynamically BUILDING a filter. How to RUN that dynamically built filter is a different kettle of fish.

Player names for a game are each stored in their own dedicated fields.

The filter to get the list of sorted names is not a hard filter to build.

Although I’ll be using a static filter, I wondered how I’d go about using a dynamic filter.

Using syntax that I prefer, a dynamically built filter assigned to variable “f”, a list widget MIGHT look something like (just my personal preference):

<$list filter={{{ [<f>] }}}>
...
</$list>

PLEASE NOTE: Seasoned users of TiddlyWiki discourage my preference for {{{ [<f>] }}}; consider using the subfilter operator if you prefer that and/or want to comply with the preferences of seasoned members in this community.

At the moment, the “Games Manager” tiddler gets a list of players with a filter that statically considers at most five players for a game.

image
image1371×838 77.6 KB

The code in the image:

\define l() =[{!!p
\define r() _🧑}!is[blank]]
\define s() +[sort[]]

<$let f1={{{ [range[1],[12]] +[addprefix<l>] +[addsuffix<r>] [<s>] +[join[ ]] }}}>
''the filter I need:'' <<f1>><br><br>
</$let>
2 Likes
Food for thought: "Travel light"
#2

Since variable “f” contains filter syntax, then you can just write:

<$list filter=<<f>>>...</$list>
1 Like
#3

Definitely.

However, if “f” is a base part of a filter, with other additions to it on a case by case basis, then the {{{ }}} allows for on the spot additions to that base part of a filter.

That aside, the curly brackets notation helps make things stand out a little bit. I find myself “overloaded” by too many of the same symbols going on, especially when I get to the << >>> sandwich.

Often, I find “too much” conciseness makes things less readable/decipherable. Respect to folk whose brains prefer that, but that ain’t for this kid.

1 Like
#4

In that case, I would tend to use

<$list filter="[subfilter<f>] +[subfilter<x>] ...">

rather than using

<$list filter={{{ [<f>] [<x>] ... +[join[ ]] }}}>

since the former makes it even more explicitly clear that the filter is constructed from separate variables that are themselves filter runs.

#5

That makes a lot of sense for all who like to use the subfilter operator.

There are a whole bunch of filter operators I prefer to avoid because I don’t particularly like them. I prefer “travel light” in regards to the number of filter operators I use. (Less stuff to remember, less stuff I need to keep looking up.)

#6

I certainly understand.

In this case, though, I think it’s too bad, as this is precisely what subfilter is designed to do:

select titles from the parameter interpreted as a filter expression

#7

I find your thought, and the expression of it, odd. That’s like a “oh dear me, poor you.”

That’s like me saying it is too bad you don’t like peanut butter and jelly sandwiches. What does it matter if you don’t like PB and J ? Why should I care?

Or you saying to me that it is too bad I prefer to use a manual can opener instead of an electric one.

I don’t get why anybody would find another person’s preference “too bad.” That is really strange to me.

If you were to say “it’s too bad your car won’t start because of the cold weather”, that I understand.

Oh yeaH; I know what the subfilter operator does. Like I said, I don’t particularly like it and I don’t want it taking up space in my sponge. “No means no” can be hard to accept sometimes…

#8

Please read it as, “for your requirements, it’s a shame that subfilter is on the list of ops you don’t want to use, as it seems custom-designed to do what you’re asking for.”

#9

What am I asking for other than the joy of building things in a way that works for me?

Life is too short to spend it conforming to what other people prefer ON MY PERSONAL TIME.

If you want to pay my bills, I’ll do things however you like 'em.

#10

@Charlie_Veniot a lot of us enthusiasts have a continuous improvement and learning process we apply to TiddlyWiki.

I appreciate you have a different approach and world view, and you are welcome to that, but I do think you need to watch out for reverse discrimination, it is perfectly reasonable for people to pursue these optimisations even if you do not. Do remember the vast majority of people come here via interest and search and we do need to try and make content useful to the greater audience.

I appreciate insight into you alternative ways and as a community we have often looked into issues such as screen readers, color blindness and other cognitive challenges.

The issue is you declare a preference for ignorance, that is intentionally not using things, but asking for solutions, people expect to learn things, that is they are trying to wipe away their ignorance. I think you would get more value exploring what the community has to offer and if something you learn is too fiddly then choose not to use it or find another approach that works for you.

  • I for one have long thought of the subfilter operator as simply the “filter operator”, because its not very sub. This is how I cope with it, but I don’t tell people they need to understand this.
  • It is hard for us to know what is appropriate for you, and I am struggling with my own conceptual models and details about TiddlyWiki

I hope you are not offended but you have voiced your position many times, I hope sharing my position informs you a little more.

#11

You tell me that I “choose ignorance”, and you ask me to not be offended?

I never expect any soul on this planet to ever want to do anything in a way I approach things

I share things only to trigger other folks’ own creativity. Kind of like somebody at a meeting sharing the most ridiculous idea, that can lead to somebody realize the best idea ever.

To all: If you don’t like what I post, then ignore what I post, or create your own wiki article that counters whatever I post in a way that you feel is best for the community

I would be happier to post and be ignored than to post and be pressured into operating in a way I can’t operate (or, for me, sucks the joy out of thngs).

I do not understand what your issue with me is, at all.

#12

Private message to be sent in an attempt to stop a flame war

#13

That is the kind of thing that is nice to do before taking a dump in a person’s bowl of corn flakes.

But then, I prefer ignorance, so what do I know.

#14

I am going to stop responding, and I am not going to send a Direct message, because you make me furious. Maybe when I have calmed down about your belligerent attitude I will consider sending it.

That is my point and if you don’t try and understand why I said it, your a lost cause.

Go ahead have the last word, I am outa here.

#15

Hi Charlie, I think the “dynamic filter” is a good topic that doesn’t get brought up much. The need arises more often than I would have expected in my own wikis to essentially “build filter strings” using filters themselves.

I think in most of my wikis now I actually have global variables setup where <lb>=[ and <rb>=] which is pretty much the same concept to what you’re using here. Every once in a while I wish that there was a cleaner way of doing that without storing and using variables. Something like a universal setting that within a filter string, something like the ⌈ ⌉ unicode characters could be used and they’d get swapped into the [ and ] characters automatically. Maybe there’s a way to do that, as I think it’d be much easier to read the code later.

Speaking more generically about “dynamic filters”, I also use the {{{ }}} a ton for this kind of thing, but I’ve been finding more use-cases where the newer notation allows things to be built pretty cleanly without a lot of extra variables.

For example, the filter operators that have suffixes. Simple example might be search because while it defaults to text and title, can be pointed at any field.

Say you wanted a list of tiddlers with a created date containing 2025, you could do:

<$list filter="[search:created[2025]first[10]]">

</$list>

But from a dynamic filter perspective, you might want a drop down or something that allows you to swap out the field searched. Written using the substitute filters allows you to swap in different suffixes.

\define myfield() created

<$list filter=`[search:$(myfield)$[2025]first[10]]`>

</$list>

Anyways, just throwing out other things I’ve learned on the subject. I try to contribute ideas where new users might find these threads to look for all of the different ways people use the tools provided to spur creativity.

#16

I spend every waking second continuously figuring out how to reduce cognitive overload, because my cognitive plate is always overflowing.

That’s why I ignore the great majority of the threads of discussion on this site. It is too much to manage. My plate is already overflowing.

Same with your post. Too much info, too long, sending me into dysfunction. The replies to my post are too many, and not focused on the goal of the post: how to build a dynamic filter.

Everybody wants to talk about how to “RUN” the filter, when all I’m doing is sharing a way of “BUILDING” a filter.

Too much information to process. Information overload. Cognitive overload. Dysfunction.

I can explain what is in my head related to my original post, but I can’t really handle the addition of more thoughts (especially diverging from the original intent) and more thought processing.

What you’ve written, it looks great, but it is too much. My plate is overflowing.

I think it would benefit the community if you re-wrote that as a dedicated “wiki” type of post, to make it visible to other community members.