[TW5] Passing a Transcluded Field Value to a Filter

[Scott Simmons (Secret-HQ)]

Following up on answers to an earlier question of mine, I've torn up and reinvented my daily to-do lists again — and run into a puzzling new problem.

In a nutshell:  I'm creating individual tiddlers for tasks I have to do for various clients/customers/my wife.  I use a macro (<<todolist>>) to print out the running list of items on a per-client basis (e.g., <<todolist TheBoss>>).  I use a button and faux checklist to check off items from these lists, tagging the tiddlers "√ done" and setting fields for completion date and completion time.

In my daily journal tiddler, I use calls to another macro (<<donelist>>) to record what I accomplished today.  Each journal tiddler has a field named today that contains that day's date in YYYY-0MM-0DD format (e.g., 2016-01-14).  The <<donelist>> macro uses <$list> to check for tasks whose completion date is equal to the today field of the current tiddler.

Or, at least, that's how it's supposed to work.

Here's what the <<donelist>> macro definition looks like:

\define donelist(client on:{{!!today}})
!$client$

<$list filter="[!has[draft.of]tag[$client$]tag[tasks]tag[√ done]task_completiondate[$on$]sort[task_completiontime]sort[task_completiondate]]">

<<donelist-listitem $client$>>

</$list>
\end

You'll notice I've set it up to accept an optional secondary parameter, on, because I sometimes want to call a list of things completed on a different date.  If I push the current date through in the macro call (e.g., <<donelist TheBoss 2016-01-14>>), my list generates perfectly — but if I leave off that parameter (<<donelist TheBoss>>)  and count on the today field to provide that value for the macro, the list fails to including anything.  The string from today is captured, and I can print it out via the macro — but it seems to be failing in the filter.

$client$ works O.K. in the filter string, as do other parameters I pass into <$list> filters elsewhere. but maybe TiddlyWiki isn't parsing {{!!today}} in the filter definition?  Can anyone confirm whether I'm barking up the right tree — and maybe suggest an alternative?

[Tobias Beer]

Hi Scott,

If you could post a minimal demo somewhere to play with,

this would be easier to test and play with possible solutions.

Best wishes,

Tobias.

[Scott Simmons (Secret-HQ)]

Thanks for the suggestion, Tobias!

I believe I've managed to boil it to down the actual issue here:

http://tiddlywiki.secret-hq.com/testing/PassingFieldValueToListFilter.html

Nevermind the to-do-list applications.  The root problem is my inability to have a macro check a tiddler field and pass the value from that field into a filter.  I believe it's related to the order in which values are fetched and wikified.  I've also included two alternate approaches in the test case, so you can see what I've tried that hasn't borne fruit.

EDIT:

Secret-HQ.com is down right now, so if it isn't back up by the time you stumble across this thread, you can download the test case TiddlyWiki from Dropbox:

https://www.dropbox.com/s/f3mv1723mfpuljy/PassingFieldValueToListFilter.html?dl=0

[Tobias Beer]

Hi Scott,

Ok, if you're not so puritan as to only want to rely on core features,

I think with some rudimentary studies of how tobibeer/setvars works,

you will have your required conditional logic set up in no time.

Best wishes,

Tobias.

[Scott Simmons (Secret-HQ)]

Of course!

I had setvars in the 5.1.9 TiddlyWiki I'd been playing around with for the last couple of months, but I started fresh with 5.1.10 and hadn't thought to bring it over.  (To be honest, I thought it was a core widget I just hadn't dug into yet!)

Looking at the documentation, it's more powerful than I realized — and seems, at a glance, to be just what I'm looking for.  It's Friday evening here, so this pot of tea and I are about to settle in and give it a shot!

[Scott Simmons (Secret-HQ)]

<$setvars> to the rescue!

After playing around with if-then statements unsuccessfully, I managed to dial it back to just using <$setvars> to scoop up and parse the input AND to build the filter string for the <$list> widget as a variable, which I could then pass in to <$list>.  That seems to have smoothed over any inconsistencies in my macro parameter sometimes being taken literally and sometimes being taken as a transclusion.  (There may still be some value in Jeremy taking a look at the test case, since this may be something he wants to tweak in the core.)

Here are the revised macro and its output, in case you want to see how <$setvars> got me through:

Backtracking, I was almost able to do the same thing with <$set> and an emptyValue, but the inconsistency in how that variable got used in different contexts (as {{!!field}} vs as value) kept getting underfoot.  <$setvars>, it seems, was able to "flatten" it to a simple variable with a text value.