Invaluable advice i have received from this forum

#1

i have been reading (and increasingly contributing to) this forum for a little while now, and this one piece of advice has been the most valuable in troubleshooting transclusions in links in macros in widgets… etc etc. it is this:

  1. widgets can’t be nested inside of widgets
    e.x <$list filter=<$transclude/>/> doesn’t work.
  2. shorthand forms (like <<macrocall>>, {{transclusion}}, [[link]]) can’t be nested inside of other shorthand forms
    e.x <<mymacro {{!!myfield}}>> doesn’t work (this one in particular perplexed me for a while!).
  3. However, shorthand forms can be nested inside of widgets!
    like <$transclude $variable=mymacro param={{{[filtered transclusion]}}}/>

this guiding principle has saved me a ton of time in troubleshooting and figuring out how to put all the pieces of the puzzle together, so i figured i’d spell it out in case anyone else would find value in it. gone are the days of wondering why my macro is returning {{nonsense}} or which of the methods of transcluding something will magically play nice together…

all thanks to the super helpful community here :slight_smile:

8 Likes
#2

Thanks for spelling it out, as you termed it. I think I was intuitively aware of this, but having it clearly stated helps! I think this info nicely compliments this explanation of what the different brackets are doing:

3 Likes
#3

Thankis for sharing your perspective @Scribs, these are importiant learnings;

  • I am however tempted to revise you first item because it makes a useful point but misdirects a little.
  • Actualy the example you give would be better stated.

Widgets can’t provide a value to an attribute (this is not nesting)
e.g <$list filter=<$transclude/>/> doesn’t work, because the value is a widget.

Because this is what we mean when we nest widgets, and we can nest widgets;

  • If it helps understand this, think of widget as responsible for displaying things not (as a rule) to provide a value to a set/vars/let (excluding action widgets that are different".
  • There are some exceptions like the text attribute of the wikify widget, but that getsmessy.
<$list filter=" any filter ">
   <$link/><br>
</$list>
  • In this case we nest the link widget in the body of the list widget.
  • Nested list widgets are a very powerful tool.

No need to add complexity, here but when one of these apparent limitations appear there is almost always a work around.

For example a work around for;

<$list filter=<$transclude/>/>

If transcluding the current tiddler, as a filter value, let us assume the filter is in a tiddler that is not the current tiddler. Let us call it “myfilter” and it contains [tag[TableOfContents]] we can write;

<$list filter={{myfilter}} />
  • As you demonstrated.

Also in item three you use the new 5.3.0 version of the tranclude widget, it remains just as useful to use the existing $macrocall widget to replace the short form of a macro call.

<$macrocall $name=mymacro param={{{[filtered transclusion]}}}/>

or

<$macrocall $name=mymacro param={{!!myfield}}>>

I have discovered the macrocall widget works with both \define macroname() and the new \procedure procname() and honors most (if not all) the new features.

Enjoy.

3 Likes
#4

Using a \procedure should fix that problem now.

\procedure myProc(x) <<x>>
 
<<myProc {{!!myField}}>>

image
image2392×1003 124 KB

2 Likes
#5

That’s a parser problem with the same “end-symbol”. eg:

<<outerMacro param:<<innerMacro>> >>

Macro inside macro does not work because the parser uses the closing braces >> from the innerMacro as the closing braces of the outerMacro. That’s a weak point of the TW parser.

The same is true for <$list filter=<$transclude/> >[. . .]</$list>
The first closing brace /> that the list-widget parser sees is the one from the transclude widget. That’s the same weak point.

1 Like
#6

this is massive! thank you! another win for the procedures, i am seeing more and more every day why they are so good for the platform.

and as for the same closing symbol, i dont actually try to use widgets as parameters for other widgets - it is more just included for completion’s sake :sweat_smile: it is pretty clear to me why this doesn’t work.

#7

it’s true, nesting widgets usually doesn’t mean “use a widget as an attribute for another widget”. coming from a programming background (at least more so than a markup background), i used “nesting” here as “using some structure inside of itself” more generally. thanks for the clarification!

and yep, i know there are workarounds - that is sort of the point of the post, to say “if you are trying to do X and it doesn’t work, try structuring it differently”

1 Like