AdvancedFilterTiddlers Plugin (supporting fields and AND statements)

20 views
Skip to first unread message

rakugo

unread,
Dec 7, 2009, 8:35:05 AM12/7/09
to TiddlyWiki
I've been getting increasingly frustrated with the TiddlyWiki
filtering in the core in that it
* does not support and filtering
* does not support fields

I wanted a filtering mechanism that worked with DefaultTiddlers in
particularly I was finding with my TiddlyWeb development I
increasingly wanted to use the filter [server.bag[bagname]] in my
DefaultTiddlers tiddler where server.bag is a custom field TiddlyWeb
defines.

I was determined to use a syntax such as [tag[tag1]tag[tag2]] for and
filters as it seemed to quite readable syntax.

Turns out it was a bit of a can of worms, I noticed lots of people
have tried to solve this problem and problems faced involved code
size, code readability and from a development point of view issues
with defining regular expressions to match the different syntaxes.

I've been a bit alternative and have created a version of the function
without any use of regular expressions, instead resorting to defining
a finite state automata (http://en.wikipedia.org/wiki/Finite-
state_machine) and in doing so proved my self wrong when I said
several years ago at uni that "this will never be useful to me".

It's pretty powerful and I imagine it is very useful in conjunction
with the list macro already in the core, so I imagine it's not just me
that will find this useful.

I've constructed a TiddlyWiki which explores the possibilities of what
you can do with this plugin:
http://www.jonrobson.me.uk/development/AdvancedFilterTiddlersPlugin/index.html

Word of warning - the plugin overrides the sortTiddlers and
filterTiddlers core functions.
Hope someone else finds this useful.
Jon

jnthnlstr

unread,
Dec 7, 2009, 2:08:50 PM12/7/09
to TiddlyWiki
Wow. Interesting way to approach the code. Nice work.

I guess with this filtering thing it's not really a core requirement,
hence why there are 3+ different plugins to solve the problem. What
amount of filtering syntax would you say is definitely a core
requirement? I can't see that the (int) (float) etc. stuff is
particularly common.


J.
> you can do with this plugin:http://www.jonrobson.me.uk/development/AdvancedFilterTiddlersPlugin/i...

Anthony Muscio

unread,
Dec 7, 2009, 11:54:44 PM12/7/09
to tiddl...@googlegroups.com
Great work.

When there is more than one plugin for a similar requirement and that requirement is pervasive amongst tiddlywiki users, and if that requirment is not a size hog then surly it should be in the core ?

This type of solution combined with the ability to add remove tags according to filtered results would be great in the core. By core I assume it can be accessed by other means than just the list command.

Tags and there manipulation setting/un-setting if exist/not exist, toggling, cycling etc.. could also be developed to generalise tiddlywiki in a similar way to it's other current open and flexible features (Java/HTML/Wiki Words links and references).

Tags should be able to be manipulated with standard set logic. I will endeavor to define clearly and post.

Thanks Jon

TonyM

If you have not found an easy way to do it with TiddlyWiki, you have missed something.
www.tiddlywiki.com



--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To post to this group, send email to tiddl...@googlegroups.com.
To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.



Eric Shulman

unread,
Dec 8, 2009, 12:22:42 AM12/8/09
to TiddlyWiki
> * does not support and filtering
> * does not support fields
> I was determined to use a syntax such as [tag[tag1]tag[tag2]]

http://www.TiddlyTools.com/#MatchTagsPlugin

provides a robust tag filtering syntax using full Boolean-logic (AND,
OR, NOT, plus nested parentheses as needed). You can also use regular
expressions to match *patterned* tags (e.g., use "foo.*" to match any
tag starting with "foo").

Also, to sort the results by *any* tiddler field, you can use the TW
*core* syntax:
[sort[fieldname]] (ascending)
or
[sort[-fieldname]] (descending)

note: although custom fields are entered and stored as text strings,
if the field values are numeric digits, then sorting *will* be
performed numerically (e.g., "1", "2", "3"..."10","11", etc.) rather
than by text comparison (e.g. "1", "10", "11", "2", "3", etc.)

Thus:

[tag[(foo OR bar) AND NOT (mumble AND gronk OR snork)]][sort[-
priority]]

enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios

Anthony Muscio

unread,
Dec 8, 2009, 12:40:03 AM12/8/09
to tiddl...@googlegroups.com
Eric,

I agree you have a great tool in MatchTags Plugin, However as posted before I do not know how to use it with my Tags that have leading special characters so I cant use it at all, practically.

Great work never the less.

rakugo

unread,
Dec 8, 2009, 9:06:20 AM12/8/09
to TiddlyWiki
I think syntax is never something everyone will agree with. Personally
I think AND and OR statements are too 'programmy', set notation is too
'mathsy'. A lot of TiddlyWiki users can't do javascript but are
familiar with the wiki syntax which this syntax closely resembles.

You *definitely* without a doubt get a lot more power with how you
have developed MatchTags but in the example you give above as I look
at that for the first time I would say that is extremely complicated
to get your head round with what your filter actually does.

Being forced to write the filter in a less expressive syntax I would
argue encourages a better end result, where if you came back to it a
year later you wouldn't think what on earth was I doing here which you
might be with your above example!! :).

In your above algebraic formula, I am pretty sure that could be
simplified (although right now I dont have the energy to do so and
could maybe be expressed the same in a longer more readable filter
(well in my opinion anyway):

eg. something like this...
[tag[foo]tag[!mumble]tag[!gronk]]
[tag[foo]tag[!snork]]
[tag[bar]tag[!mumble]tag[!gronk]]
[tag[bar]tag[!snork]]
[sort[-priority]]

If the filter cannot be expressed in such a way it might suggest you
need to arrange your data better - eg. invent a new tag for example.

Also in your syntax how would you allow it to work for fields without
it becoming really incomprehensible?
eg. if you wanted everything tagged with foo or bar with the field
mumble set to gronk what would this look like?

I think this a really interesting and valuable conversation to have so
lets keep it going..
Jon
Reply all
Reply to author
Forward
0 new messages