Some coding fun: "check boxes" that add/subtract from same field

Charlie Veniot

unread,

Oct 5, 2021, 7:02:09 PM10/5/21

to TiddlyWiki

Of course, for me, it is always about "brain-age games" (how would I do "this") and the fun of filters ...

Drag the attached into some TiddlyWiki (TiddlyWiki.com!) and give the one tiddler a gander.

CheckboxesSavingToSameField.json

History Buff

unread,

Oct 5, 2021, 7:34:42 PM10/5/21

to TiddlyWiki

I've been using the macro found here to do that for quite some time: http://toggle-in-field.tiddlyspot.com/

Charlie Veniot

unread,

Oct 5, 2021, 8:08:34 PM10/5/21

to TiddlyWiki

That's a lot fancier than what I was aiming for in much more compact code. Pretty cool.

Looks to me like that it is past the "Beta" stage.

Mat

unread,

Oct 6, 2021, 4:56:07 AM10/6/21

to TiddlyWiki

Thanks for referencing my old http://toggle-in-field.tiddlyspot.com/

One reason for it to be in beta is because of the (somewhat embarrassing) use of faux checkboxes (they're images!)

I obviously agree there is a need for this, so I made an issue request for a real solution. If you agree with the request, please give it a like or comment in the thread there. I was hoping this would be solved with the latest TW release but evidently it was not.

<:-)

Charlie Veniot

unread,

Oct 6, 2021, 8:33:53 AM10/6/21

to TiddlyWiki

Your images are quite nice. Besides, "real" checkboxes in HTML, aren't they pretty much images?

I say un-Beta that bad boy.

TW Tones

unread,

Oct 6, 2021, 9:02:46 PM10/6/21

to TiddlyWiki

It is interesting the conversation in the github discussion issue request for a real solution.

But twMat I think your solution is a real solution and does not necessarily need a core widget improvement, but it would be good, since this could be a common use feature.

I suppose the conversation could/should continue there in github, but I was wondering if a simple solution would be if the checkbox widgets checked and unchecked fields accepted filters that is they were treated as strings like currently unless they start with a "[" and if so first evaluate the filter to obtain the value. However the below may be a better solution. Because otherwise the two filters may need to match and I am not sure filters can handle the two purposes that checked and unchecked provide.

The trick is these fields are used for two purposes one is to test the other is to set the state. This is easily the same thing when a simple string toggle is in place, but not if we want to use listops to handle multiple values in a field.

Then I thought if the string is prefixed with either a + or a - this implies it is a list ops function. So if the checkbox widget encounters a string with one of these prefixing it it uses list ops instead.

The following could be applied to any field however it replicates manipulating tags.

```<$checkbox field="tags" checked="+mytag" unchecked="-mytag" default=" -mytag"> Is it open?</$checkbox>```

So if the +mytag was encountered the checked test would be `[contains:tags[mytag]]` and the unchecked `[!contains:tags[mytag]]`

and the reverse of the +- is reversed.

The action on click for each would be to provide the "signed value" to the listops subfilter.

We should however allow pseudo filters still to be passed eg; "+[[a tag/value with spaces]]" or "+[has[fieldname]then[client]else[friend]]" as long as they resolved to a string that can be given to the contains test and listops subfilter.