Use Field values as input titles

#1

HI,

I have Tiddler1, which has Field1., which holds the value “tiddler2 tiddler3”
i want a button to to update field2 in Tiddler2 and tiddler3 , using the value stored in Field1 in tiddler1 as input titles

<$button>update
<$list filter = "[<currentTiddler>{!!field1}]">
<$action-setfield field2 ="blabla"/>

when i do this ,the value in field1 is not interpreted as a group of titles, but instead as one tittle"tiddler2 tiddler3" and ends up creating a tiddler called “tiddler2 tiddler3” then taking the action there

how can i make the separation , and if this is a wrong approach then what would be the right way of this

thank you

1 Like
#2

Use the enlist filter operator:

<$button>update
<$list filter="[enlist{!!field1}]">
<$action-setfield field2="blabla"/>

Notes:

  • When specifying parameters, do not put spaces between = and the corresponding "literal value" parameter value.
  • Except when using certain filter run prefixes (e.g., :filter[...], :map[...],etc.), {!!fieldname} will always refer to a field in the current tiddler (i.e., the tiddler in which the $list widget occurs), so the preceding <currentTiddler> is not needed.
  • enlist{!!fieldname} processes the contents of {!!fieldname} as a space-separated bracketed list of items and split it into separate items for further processing. Note that enlist... is a “filter constructor”, and ignores anything that precedes it. To enlist somefield value from SomeTiddler, you would use [[SomeTiddler]get[somefield]enlist-input[]]
2 Likes
#3

Is this stylistic/space-saving advice or are there practical consequences in TW not found in HTML?

#4

This USED TO BE a limitation of the widget parameter parsing, but it seems to no longer be the case and spaces ARE permitted.

I tested this using:

<$let test="value"><<test>></$let>
<$let test2 = "value2"><<test2>></$let>

which correctly displayed as:

value value2
1 Like
#5

Ok, thanks. I was pretty sure that I’d successfully used spaces there, since I often do so in HTML. But I was wondering if there were some subtle edge cases I hadn’t run across.

Thanks for the speedy reply!

#6

Funny. I like the tighter binding in HTML. I’m not a fan in JS.

#7

I’m coming off a several-year kick of using a great number of spaces in JS in places where others usually don’t. I still prefer that style, but I’m tired of the strange looks, and am trying to switch back.

Still really, doesn’t this just look so pleasant?: :grinning_face_with_smiling_eyes:

const setPath = ([p, ...ps]) => (v) => (o) =>
  p == undefined ? v : Object .assign (
    Array .isArray (o) || Number .isInteger (p) ? [] : {},
    {...o, [p]: setPath (ps) (v) ((o || {}) [p])}
  )

const hydrate = (xs) =>
  xs .reduce ((a, [p, v]) => setPath (p) (v) (a), {})

Look at all that glorious whitespace!

1 Like
#8

Needless to say, I suppose, I’m a little less than comfortable reading TW core js(arg1,arg2,somethingElse,splurge)

Let me breathe!

#9

In tiddlywiki

I avoid the spaces around the = because spaces delimit pairs of parameter value pairs and it is easier to scan the code to read it. Otherwise spaces no longer only delimit the parameter/value pairs.

I am all for adequate whitespace but not where it may add ambiguity or reduce scanability.

#10

@EricShulman Thank you for you help