Filter, meta actions, Discussion

#1

Folks it is quite common to want to alter the results of a filter, the most common may be altering the sort order, or field on which to sort, or adding the negation !.

I know there are a number of ways to do such a parametised sort, and I am not asking for those here, but I want us to discuss the idea of constructing filters before we use them. A common way would be using backticks as an attribute, when defining a variable to be used as a filter, or on a filter= parameter as an attribute value. Or even the deprecated define, or new substitute operator.

I have long thought we could as a community develop a shared “best practice” for programmatically defining and constructing filters, before their use.

Filters are so important to TiddlyWiki and there are numerous tips and tricks available out there, but when one goes beyond correcting filters, or sharing self contained filters, it is difficult to research and publish filter tricks without having to build a full and precise filters and examples.

  • For example consider the use of this in a function to turn it into a list +[format:titlelist[]join[ ]] it can just be appended to a filter but what if it was only a sub filter.

Some authors and many users would love to have written guides on how to construct filters, beyond the per operator documentation, including dial on demand filter generation to use in our “TiddlyWiki Script”. Until we have a collection of methods to handle constructing filters we cant progress this much further. This would help the community;

  • write interactive filter generations tools
  • provide more sophisticated documentation and interactive lessons.
  • Communicate more readily when supporting complex filter problems.

So to be clear this is a meta view of constructing filters, to subsequently use as filters.

What are your thoughts?

#2

I think it always depends on the usecase and the “flow” of the code.

  • I often start simple and then refine my filters with several iterations.
  • Now I mainly use functions, because they are easy to test and debug afterwards
  • I avoid it to make “monster” filters, that try to do everything in one run, because they are hard to debug

That’s basically it.

2 Likes
#3

So-called best practice achieves one thing remarkably well: prevention of innovation.

Had @jeremyruston stuck to best practice, TiddlyWiki would have never been a twinkle in his eye let alone become the software we all know and love today.

As for the sentiment you expressed, especially improved user guides re filters, sure, and of course. But I also agree with @pmario 100%; I have to understand the filter 6 months from now. If it gets too convoluted or complex, all I’ve done is confuse future-me. :confused:

#4

interesting attitude to “best practice”, I did suggest we develop one. It is more a target or a process than some fixed thing. once you get close to such a thing, changes and innovation may very well move the goal posts and what may be best practice changes, but all such things demand continuous improvement and bending and breaking such practices something I encourage with all systems and rules.

However I do think a collaborative process can help us avoid the use of bad practices, ones that make our code hard to understand, learn, maintain and change.

one thing is I suggest focusing on a neglected part of tiddlywiki and putting a collective focus on it will inform us and help guide development of filters which is becoming more complex with every release. what I ask about here would make a good foundation even just to improve how we discuss and document filters.

#5

Mario,

my approach is similar to yours, but I think we can share more of our tacit knowledge to new and experienced users a like. Key to this is how we write about, display, document and provide examples.

one observation if you look at the documentation is most filter examples use literals, and are usually very brief and still leave a lot out.