[TW5] Template Transclusion Within <$List> Widget

1,032 views
Skip to first unread message

Scott Simmons (Secret-HQ)

unread,
Jan 30, 2016, 10:21:28 PM1/30/16
to tiddl...@googlegroups.com
I have some newhere buttons I'd like to transclude into different tiddlers.  Naturally, I want them to behave as if currentTiddler is the including tiddler, not the tiddler where the button lives.  (For example, I want to assign the tags of the tiddler from which the button is clicked, not the tags of the tiddler where the button is defined.)

Rather than resorting to macros, I'm know I can invoke those buttons with template transclusion (e.g, {{||MyButton}}).

But how can I use template transclusion within the <$list> widget?

This doesn't seem to work:

<$list filter="[my[filter]]"><$tiddler><$transclude /></$tiddler></$list>

Nor does this:

<$list filter="[my[filter]]"><$tiddler tiddler=<<currentTiddler>> ><$transclude /></$tiddler></$list>

Nor this:

<$list filter="[my[filter]]"><$transclude tiddler=<<currentTiddler>> /></$list>

Well — they work in the sense that the button is transcluded, but it fails to treat the including tiddler as currentTiddler, instead defaulting to the tiddler where the button is defined.

Is this a limitation I've stumbled up to, or (more likely) am I just missing an obvious syntactical solution?

Eric Shulman

unread,
Jan 31, 2016, 1:25:50 AM1/31/16
to TiddlyWiki
On Saturday, January 30, 2016 at 7:21:28 PM UTC-8, Scott Simmons (Secret-HQ) wrote:
Rather than resorting to macros, I'm know I can invoke those buttons with template transclusion (e.g, {{||MyButton}}).
But how can I use template transclusion within the <$list> macro?
This doesn't seem to work:
<$list filter="[my[filter]]"><$tiddler><$transclude /></$tiddler></$list>
Nor does this:
<$list filter="[my[filter]]"><$tiddler tiddler=<<currentTiddler>> ><$transclude /></$tiddler></$list>
Nor this:
<$list filter="[my[filter]]"><$transclude tiddler=<<currentTiddler>> /></$list>

Have you tried:
\define trans() {{||$(x)$}}
<$list filter="[my[filter]]" variable="x"><<trans>></$list>
* using variable="x" prevents the $list widget from changing the current tiddler context.
* the trans() macro assembles the transclusion syntax using the current value of "x"

Thus, if your filter matches tiddlers A, B, and C, the resulting $list output is:
   {{||A}} {{||B}} {{||C}}
which renders A, B, and C using the current tiddler context.  Q.E.D.

Note: I thought that the <$transclude> widget had params for both tiddler="..." and template="...", so that template transclusion using variable params could be done without needing a macro to assemble the {{tiddler||template}} syntax... but it doesn't seem to be the case.

enjoy,
-e

Tobias Beer

unread,
Jan 31, 2016, 2:46:14 AM1/31/16
to TiddlyWiki
What's wrong with using either of:

<$list filter="...">
{{||template}}
</$list>

Or then...

<$list filter="..." template="template title"/>

?

Best wishes, Tobias.

Eric Shulman

unread,
Jan 31, 2016, 3:57:14 AM1/31/16
to TiddlyWiki
On Saturday, January 30, 2016 at 11:46:14 PM UTC-8, Tobias Beer wrote:
What's wrong with using either of:

<$list filter="...">
{{||template}}
</$list>

Or then...

<$list filter="..." template="template title"/>


The $list widget is being used to get the names of the buttons to transclude into the currentTiddler context.  However, when the $list widget is processed, the currentTiddler *within* the widget content is a "button tiddler", not the tiddler in which the $list is embedded.  To achieve the proper results, we need to keep the currentTiddler context unchanged within the $list, and use a different list variable to get the *template* name used to construct the {{||template}} transclusion syntax.

-e

Tobias Beer

unread,
Jan 31, 2016, 5:25:05 AM1/31/16
to TiddlyWiki
Hi Eric,
 
The $list widget is being used to get the names of the buttons to transclude into the currentTiddler context.  However, when the $list widget is processed, the currentTiddler *within* the widget content is a "button tiddler", not the tiddler in which the $list is embedded.  To achieve the proper results, we need to keep the currentTiddler context unchanged within the $list, and use a different list variable to get the *template* name used to construct the {{||template}} transclusion syntax.

Thanks for clarifying, I didn't get the actual goal of it all.

Yes, a list variable should do the trick.

<$list filter="[get[those_buttons]]" variable="button">
<$transclude tiddler=<
<button>/>
</$list>

Best wishes,

Tobias.

Eric Shulman

unread,
Jan 31, 2016, 9:00:16 AM1/31/16
to TiddlyWiki
Not exactly enough though.  The $transclude above will embed the buttons, but doesn't use them as *templates* for the currentTiddler.  Thus, the problem in the OP: how to transclude the buttons, but have them work on fields in the transcluding tiddler.

I had thought that $transclude supported both tiddler="..." and template="...", so you could write something like:
<$transclude tiddler=<<currentTiddler>> template=<<button>>
which would be the equivalent to {{||buttonname}}, but using a widget so you can use the template name defined in the "button" variable.

However, looking at the underlying transclude.js widget code, there doesn't appear to be any support for handling a "template" param in the widget.

-e



Scott Simmons (Secret-HQ)

unread,
Jan 31, 2016, 12:11:21 PM1/31/16
to tiddl...@googlegroups.com
On Sunday, January 31, 2016 at 1:25:50 AM UTC-5, Eric Shulman wrote:

Have you tried:
\define trans() {{||$(x)$}}
<$list filter="[my[filter]]" variable="x"><<trans>></$list>
* using variable="x" prevents the $list widget from changing the current tiddler context.
* the trans() macro assembles the transclusion syntax using the current value of "x"

I had hoped to avoid macros altogether (one less thing to remember about an exceptional case if I transclude newhere buttons from time to time in the future) — but that's a dead-brilliant workaround.  I had considered using Tobias's <$setvars> to build newhere buttons on the fly in a macro, but your answer is so much more elegant.

 
Note: I thought that the <$transclude> widget had params for both tiddler="..." and template="...", so that template transclusion using variable params could be done without needing a macro to assemble the {{tiddler||template}} syntax... but it doesn't seem to be the case.

There doesn't seem to be a "template" parameter — although it seems to have been proposed a few times, given the number of times it crops up in the archives of this Group.

According to TiddlyWiki.com (and the thread here), I'd expect you to be able to use:

<$tiddler tiddler=<<currentTiddler>> ><$transclude tiddler="MyButton" /></$tiddler>

... as the long-form version of {{||MyButton}}.

That works if you write it into a tiddler on its own, so perhaps there's something about <$list> widget that throws a spanner into <$tiddler>?

Maybe this is a bug that merits a GitHub ticket?

Eric Shulman

unread,
Jan 31, 2016, 2:52:25 PM1/31/16
to TiddlyWiki
<$tiddler tiddler=<<currentTiddler>>> basically does nothing, since <<currentTiddler>> IS the current tiddler, the widget is setting the tiddler value to the *same* name and the behavior of the inner content (the $transclude) is not affected and still just performs a "simple" transclusion, rather than the template transclusion" that you want.

-e

Tobias Beer

unread,
Jan 31, 2016, 2:53:57 PM1/31/16
to TiddlyWiki
Hi Eric,

I'm not sure I follow. Please, consider the case of these two tiddlers:

title: Bar
foo
: no

{{!!foo}}

title: Foo
foo
: yes

<$transclude tiddler="Bar"/>

As expected, the tiddler Foo shows "yes"... and I am rather positive that any transcluded button is rendered in the context of whatever currentTiddler is, within a list widget.

Best wishes,

Tobias.

Eric Shulman

unread,
Jan 31, 2016, 3:24:18 PM1/31/16
to TiddlyWiki
You are correct.  I was mistaken.  My error was due to the fact that the <$tiddler> widget param name is actually naming the *template* to render, and does not set the currentTiddler, so the transcluding tiddler remains in context.  Thus, <$transclude tiddler="foo"> should be equivalent to {{||foo}}.  Thus, there is no need for the "trans()" macro I suggested in a previous post, though the use of variable="..." in the $list widget is still needed to avoid stepping on the currentTiddler context, and your suggested syntax is the cleanest:

<$list filter="[get[those_buttons]]" variable="button">
<$transclude tiddler=<
<button>/>
</$list>

-e

Scott Simmons (Secret-HQ)

unread,
Jan 31, 2016, 4:29:36 PM1/31/16
to tiddl...@googlegroups.com
Sweet!  And no macro to remember (though I do have to remember to include the somewhat extraneous-seeming variable).
 
<$list filter="[get[those_buttons]]" variable="button">
<$transclude tiddler=<
<button>/>
</$list>

I had a test case/demo I hadn't gotten around to sharing, but it's here in case anyone comes through and wants to see — now updated with the solution:



This is NOT a bug — right?  Just an edge case where the way in which parameters get wikified plays a bigger role.

Tobias Beer

unread,
Jan 31, 2016, 6:32:52 PM1/31/16
to TiddlyWiki
By the way Scott,

Pplease pay attention to the terms (perhaps revisit the docs)
<$list> and <$setvars/> are widgets, not macros. :-)

Best wishes,

Tobias.

Scott Simmons (Secret-HQ)

unread,
Jan 31, 2016, 8:31:50 PM1/31/16
to tiddl...@googlegroups.com
On Sunday, January 31, 2016 at 6:32:52 PM UTC-5, Tobias Beer wrote:

By the way Scott,

Pplease pay attention to the terms (perhaps revisit the docs)
<$list> and <$setvars/> are widgets, not macros. :-)

Thanks!  A trip back to the documentation now that I've had more time to knock about certainly couldn't hurt.

I've struggled to grok the concept of widgets, and my current conception (perhaps wrong) is that they're elements of the TiddlyWiki that (can) have child elements.  I misidentify them as macros from time to time, I suppose, but I think of macros as having their own child elements — but maybe that's an optical illusion caused by me looking at the components of macros in tiddlers and forgetting that macrocalls are a terminal node in the widget-tree (the last tips of the branches, so to speak) even if they do reference other parts of the tree.

I'll keep wrestling with it.  It's completely possible I'm (sorry) barking up the wrong tree entirely.

In the meantime I've cleaned up this thread so I don't infect anyone else with my confusion.  :P

Tobias Beer

unread,
Feb 1, 2016, 3:35:26 AM2/1/16
to tiddl...@googlegroups.com
Hi Scott,

Try to think of:
  • widgets
    • as something akin to html elements
    • the building blocks of the wiki that extend upon all of html, js and css
      • these are your lego blocks
      • even what you think of and see as "plain html" ...actually are "element widgets"
    • with enhanced capabilities that are represented in a java-script widget-tree
      • rather than the dom-tree alone of any html elements eventually rendered 
  • macros
    • are snippets of (wiki-)text that get inserted where you "call" them
      • but, they are not functions with return values
    • whatever wiki-text they hold is wikified in and by the context they are called
    • perhaps they can be thought of as a parametric form of transclusion
      • "grab that text and replace these parameters in it with those (sometimes evaluated) values"
        • then render all that (wiki-)text right here were I called you
    • these are more like lego blueprints, if you wish
      • the parameters allowing you to have it behave like a transformer
        • that may be a robot when these blocks are arranged that way or some vehicle with a few other blocks arranged another way
Best wishes,

Tobias.

Scott Simmons (Secret-HQ)

unread,
Feb 6, 2016, 5:02:19 PM2/6/16
to TiddlyWiki
Thanks for the excellent rundown on the conceptual differences, Tobias!

When the concepts are confusing, I'm trying to remember to look to the syntax as a kind of cheat sheet, also:
  • If its longhand form is <$something ... />, it's a widget.
  • If its longhand form is <$macrocall $name="something" ... />, it's a macro.
  • If it can be written in the shorthand <<something ...>>, it's a macro.

Tobias Beer

unread,
Feb 7, 2016, 10:29:05 AM2/7/16
to TiddlyWiki
Hi Scott,
 
When the concepts are confusing, I'm trying to remember to look to the syntax as a kind of cheat sheet, also:
  • If its longhand form is <$something ... />, it's a widget.
  • If its longhand form is <$macrocall $name="something" ... />, it's a macro.
  • If it can be written in the shorthand <<something ...>>, it's a macro.
Almost there. :-)

As you may have inferred from the syntax, $macrocall is actually a widget.

There are two important things to know about that:
  1. the macro wikitext syntax is actually turned into a macrocall widget when rendered
  2. using the widget allows you to use dynamically evaluated attributes which the plain wikitext syntax does not
Best wishes,

Tobias.

Scott Simmons (Secret-HQ)

unread,
Feb 7, 2016, 2:43:11 PM2/7/16
to TiddlyWiki
Those bits I grok ;) — and they're definitely worth spelling out for posterity.

This thread has turned into one of the best concepts documents on widgets vs. macros in the Tiddlysphere.  Maybe my present clarity is more a result of having spent some time using them than just reading about them, but I suspect the core documentation could use some of what's laid out here — especially your compare/contrast bullet list and the newbie's guide to syntax.

Tobias Beer

unread,
Feb 13, 2016, 2:38:33 AM2/13/16
to tiddl...@googlegroups.com
Hi Scott,

Yes, seeing as how Jeremy occasionally points out that this or that would "break the layering", perhaps a "Layering" tiddler on tiddlywiki.com would indeed be a valuable starting point to understand (the syntax elements) a little better, at least how...
  1. Core Javascript
  2. Widgets
  3. Wikitext
  4. Macros
  5. Templates
...tie-in together, possibly in that order. (anything else?).

Also, it appears there's that vertical layering and then perhaps also horizontally in terms of separation of concerns, e.g. "css" would be something affecting a range of these "layers".

Could also be a simple matrix, with three columns Model View and Controller... indicating what part of the paradigm a vertical layer mostly affects and then the most important points as to how... while linking to those detail topics.

Best wishes,

Tobias.
Reply all
Reply to author
Forward
0 new messages