Concatenating text with a field

1

suspect I am pushing my luck with TW5 here, but here is what I am trying to do.

Simply if a field exists in a tid display it:

{{{ [<currentTiddler>has:field[built]then{!!built}] }}}

That works fine of course.

Now what I really want to do is prefix the field displayed with some text "The property was built in: "

Tried this but it does not work, but it should give you an idea of what I am trying to do:

{{{ [<currentTiddler>has:field[built]then[The property was built in: ]] {!!built} }}}

This page suggests I need a macro.

So tried this:

\define linkup() [[The property was built in: |$(currentTiddler)$-built]]

<<linkup>>

Note: All my failed attempts display formatted as links when I just want plain text.

Thanks.

2

Give this a try:

\define linkup() The property was built in: <$text text={{{ [<currentTiddler>has:field[built]then{!!built}] }}} />

 <<linkup>>
3

If you don’t want to use a macro, then try:

<$text text={{{ [<currentTiddler>has:field[built]then{!!built}addprefix[The property was built in: ]] }}} />
4

Thanks, both solutions work perfectly of course. So if I want to make the macro version work for all Tiddlers, but only those tagged with “property”, how do I tweak the macro?

Thanks

5

If you really want to use a macro, you can try:

\define linkup()
<$list variable="." filter="[<currentTiddler>tag[property]]">
The property was built in: <$text text={{{ [<currentTiddler>has:field[built]then{!!built}] }}} />
</$list>
\end

…and put this in its own tiddler with the tag $:/tags/Macro

But if want something made to show in each tiddler automatically, it makes more sense to just put it as a ViewTemplate item:

<$list variable="." filter="[<currentTiddler>tag[property]]">
The property was built in: <$text text={{{ [<currentTiddler>has:field[built]then{!!built}] }}} />
</$list>

Put the above in a tiddler tagged with $:/tags/ViewTemplate

6

Since that was written, there have been some new tools added to the filter operator arsenal. In general, you can often use addprefix and addsuffix to perform concatenations. Also, there is now a map filter run prefix. So, this seems to work.

{{{ [<currentTiddler>has:field[built]] :map[{!!built}addprefix[The property was built in: ]] }}}
7

I will just add;

This can often be replaced with a get[fieldname].. because the filter only only continues if it got “fieldname”.

{{{ [all[current]get[built]addprefix[The property was built in: ]] }}}

8

I’ll probably have 50 Tiddlers so it seems to make more sense to use a generic macro.

9

Another concatenation method I have started using a lot more, especially when building a tooltip, such as on a button, is the join opperator in a filtered transclusion. In many ways its the simplest and cleanest;

{{{ [[string literal]] [{!!fieldname}] [{tiddlername}] [{tiddlername!!fieldname}] [[: ]] [<variablename>] +[join[ ]] }}}

The join does the concatenation and in this case with a blank space between each item.

11

If anyone is so inclined a PR would be very welcome, the entire tiddler is outdated.

The join operator is how the core itself does concatenation, for example when assigning CSS classes.

12

My only caution is that when parametised transclusions etc in 5.2.4+ there will be other ways.

Lets change or add to the doco but not over do it until taking account of new possibilities.

13

I can look at submitting a Documentation change, I would be keen to move the don’t do’s down and put the dos at the top.

14

I think the first section could be kept. We introduced it, because it’s the intuitive but wrong way. … It may be moved to the end to be there as an example.

So starting from: The solution is to use a macro to put the rendered value of ,,, this and the rest of the content can be completely removed and be replaced … Really nothing after that makes much sense anymore.

15

I think it can be a fast fix, which may need some iterations, but imo it should be done immediately.

16

I was forced to put those in. It was really discouraging. Maybe you’ll have a friendlier audience.

17

hmmm, There has been a discussion at GitHub about the PR and the result was merged and it lasted for 6+ years.

As Tony points out, the “intuitive non working” examples should probably be moved to the end. … https://tiddlywiki.com/#Linking%20in%20WikiText can be an example for such examples.

The concept you introduced is still valid. … As I wrote: “We may need some iterations” to get the best result possible at a given time.

18

I think this should be part of the TW documentation: https://tiddlywiki.com/#Concatenating%20text%20and%20variables%20using%20macro%20substitution

At the moment we explain it, to use macros with text substitution, which we highly discourage everywhere else.

@jeremyruston

So IMO the linked tiddler should be completely rewritten and the join filter run may be a good alternative. ..

19

@pmario can you please give me a single line why we discourage this?

It seems to me it may depend on complexity, number of items etc… when substitution is not recommended.

20

Macros which use $variable$ or $(variable)$ can’t be cached. So if they are used in templates, or in large lists, they are less performant then a join filter will be.

At the moment we don’t have a good and easy to use alternative, but there is GH issue, that we should create one

21

Perhaps then the documentation could say;

Macros which use $variable$ or $(variable)$ can’t be cached so when designing templates or lists likely to have a lot of items, it is better to make use of the the “above” filtered transclusion and join operator for concatenating values because its much more efficient.

  • As a result you may want to use this method for concatenation “as a rule”

My feeling is the idea that simple replaceable parameters is to be discouraged is overkill and will deprive everyday users of simple code patterns that are easier to understand.

  • It may be a simple effort, if and when performance issues arise, to search for $variable$ or $(variable)$ and revise the code, because in most cases this will not be an issue.