How to use the transclude widget and shorthand transcludes

Tips & Tricks
#21

@jeremyruston Zell, the doc may need a fix if not the code. I will have a try and if succesful, have a PR submitted.

Glad to see my very first suggestion seems interesting. Surely it would be enough and able to please many people.

#22

I have played with transclusions and filtered transclusions a lot. They offer a nice opportunity for user code simplification without needing global macros. I will illustrate if requested, one gap I perceive is as follows;

  • {{||template}} transcludes the template using current tiddler
  • {{namedtiddler||template}} transcludes the template using namedtiddler, which can in fact be anything and the value made use of within the “template”. the current tiddler title can be used as a parameter to the template. If you have used current Tiddler to pass another value you can use <<storyTiddler>>
  • {{!!fieldname}} will transclude the field in currentTiddler.
  • {{||template!!fieldname}} will transclude here the content of “template!!fieldname” and the content of transclude text field is ignored (understandable).
  • {{namedtiddler!!fieldname||template}} and {{!!fieldname||template}} do not pass the fieldname or its content to the template.
    • the field reference is lost.

In conclusion

  • Not all possibilities are currently catered for and the possibility of passing a little more information in a shortcut transclusion is limited, although they can access global values, local variables and macros.

Of course any facility found in the shortcut transclusions or the transclude widget should be similar, and arguably in filtered transclusions as well.

  • Perhaps we could somehow set inline or block?

I would need to revisit this as a question if we were to look at improving the transclude (short and widget) and filtered transclusion as I have only come upon these limitation’s and a range of possibilities when deep in other projects.

#23

Having a short look. I’d consider this an “oversight” or a “bug”. IMO you should open a github issue for this one.

There may be some arguments against implementing it … eg: Tiddler titles could look that way ?!

#24

Yea, I’ve missed that sometimes too. … I think there are some open github issues for this one already

1 Like
#25

See: Introduce shortcut syntax for transclusion passing parameters via variables ¡ Issue #5199 ¡ Jermolene/TiddlyWiki5 ¡ GitHub

#26

Back in the thread, I made almost the same statements I made in this one.

One remaining gap in the current macro parameters and I would hope we can avoid if we build a method to pass variables in a transclusion, is to find a way to represent all parameters.

Using named parameters as param=value or positional parameters “value1 value2” mean we must name each parameter. This means we can not design solutions with a variable number of parameters. If for example we have a special parameter name such as $*$ that could be used in macros and transclusions, that would contain the name=value or values of all parameters" then it would be easier to write solutions with an variable sized set of parameters. Which we can subsequently parse in the macro or transclusion.

#27

IMO that’s not true. With a new implementation we can have as many named parameters as we want. Core parameters may need special $names, similar to the action-widgets. But user parameters won’t have any limits.

#28

Those examples don’t really make sense – the part before the double vertical bar is the title of the tiddler that is assigned to “currentTiddler”; we can’t assign namedtiddler!!fieldname to currentTiddler.

1 Like
#29

@jeremyruston is right that {{namedtiddler!!fieldname||template}} is not allowable. But then, there is a little problem because {{namedtiddler!!fieldname}} is legal and one //will tend to think// that ||just specify a template to be used in the tiddler named on the left part. In the present example, it would be said that the name is notnamedtiddler!!fieldnamebut the value in thefieldnamefield of thenamedtiddlertiddler. If that value wasfubarthen that would be translated into{{fubar||template}}`.

The question is: is that an expected assumption or not (not a correct one, just one that we can expect in real life).

I for one does expect just that.

If I am to be wrong, then maybe we could try to devise an other wiki marking. Because if {{namedtiddler!!fieldname}} produce fubar it is rather unexpected (if not perceived as plainly illogical) that {{namedtiddler!!fieldname||template}}does not produce {{fubar||template}} but is in fact an incorrect expression.

PS : why //slash// does not produces italics ? what marking are we using here? (I’m not asking for “*” but for a name like tw5 or markdown or bb-quote.)

1 Like
#30

Use markdown syntax: _underscore_ ==> underscore

You can also use html: <i>italics</i> ==> italics

1 Like
#31

I think that the subtleties of a syntax like TiddlyWiki’s are inevitable given the complexity of the task it is designed to address. To properly understand it requires an understanding variables, which is obviously a conceptually complex topic. So we try to simplify things by making the “currentTiddler” variable be implicit as often as we can, but eventually users will have to get to grips with what’s going on if they want to do complex things.

1 Like
#32

Today I found a problem with transclude widget that was not previously told (at least, explicitely). Here it is.

I have a foo tiddler which has a field called bar, that it includes to get its text complete. The full text firld content could be:

Hello! {{!!bar}}

If I code elsewhere {{fu}} everything is nice. If I code <$transclude tiddler=fu/> it,s broken beause the currentTiddler is not //fu//. So that I have to code <$tiddler tiddler=fu><$transclude tiddler=fu/></$tiddler>. This is not a new mechanism, but for such a simple task, it seems overkill.

The coding in fu does not seem to be wrong for me. I’m reluctant to code {{fu!!bar}} instead of {{!!bar}} as it would be broken if fu is renamed (it’s less robust).

Should we not expand the include widget to allow for it to be able to be, by itself, able to do as the {{fu}}syntax? If so, an attribute like “autoref” could do it. {{fu}} would be equivalent to <$trasnclude autoref tiddler=fu/>.

#33

@jypre this has come up before with the transclude widget tiddler=theTemplate tiddler. It is equivalent to
{{||theTemplate}}

One way to think of it is tranclude is by default overlaying a tiddler template on the current tiddler. The current tiddlers title and fields can be seen “throught the template”.

If you want to transclude the tiddler without it applying to the current tiddler try {{theTemplate}}

I have actualy pushed the transclude method a lot further. So if you state your need I may be able to offer a trick or two.

Perhaps if the tranclude widget permitted a currentTiddler parameter?

#34

@pmario “if the tranclude widget permitted a currentTiddler parameter?” yes that would be nice. but it would require repeating the tiddler name, whereas an argumet like fromSameTiddler=yes would avoid that and this could be handy to build the expression from a filter run.

{{fubar}} would then be identical to <$transclude tiddler=fubar fromSameTiddler=yes/>

(or a better name than //fromSameTiddler//)

#35

Does not seem as sweet to me as taking the existing format

<$tiddler tiddler=tiddlername><!-- sets current tiddler -->
   <$transclude tiddler=templateTiddler/>
</$tiddler>

And improve it as such
<$transclude template=templateTiddler currentTiddler=tiddlername />

where template= is simply an alias for tiddler=

On further thought we can extend this further to accept any variable/value pair, and make them accessible in the transclude.

<$transclude template=templateTiddler varname=value varname2=value2/>
where providing current tiddler is just another varname/value pair.

#36

Yes I think it would make sense too since several widgets messages allows hashmap parameter (or “paramObject”) .

1 Like
#37

The technique of passing parameters to a transclusion via variables is useful, but lacks one critical element: it is not currently possible to reliably have the transcluded tiddler apply a default value for parameters that have not been explicitly specified.

I am exploring ways to add that capability (“parameterised transclusion”) with the intention that we’d use the <$transclude tiddler=templateTiddler varname=value varname2=value2/> syntax to pass parameters. For backwards compatibility, there would be an implied currentTiddler=<<currentTiddler>>parameter, but it could be overridden.

Within the transcluded tiddler, there would be something like a \parameters pragma to specify the parameters and their default values.

2 Likes
#38

@jeremyruston out of curiosity why do you consider this necessary?

apply a default value for parameters that have not been explicitly specified

As a designer I am happy to take responsibility both for providing as well as using other variables such as “varname=value varname2=value2” with the exception of the aforementioned alias parameter template for template and currentTiddler

#39

There are many use cases, but a key underlying motivation is consistency. As you know, in the core there’s an uneven mix where some of the reusable building blocks that we provide are designed as transclusions (eg the switchers like $:/snippets/paletteswitcher), while many more are provided as macros (eg the TOC macros). Broadly, the core uses transclusions where possible, but is forced to use macros in the cases where there are multiple and/or optional parameters.

For authors, the advantage is that it is possible to publish a tiddler that is designed to be transcluded, and then later add optional parameters without breaking backwards compatibility.

We would also introduce a shortcut syntax for a transclusion with parameters.

4 Likes
#40

Thanks @jeremyruston for that insight and perspective. Also I look forward to learning more on;

As you can see in this thread this was the latest issue in this thread

Which is in my view a combination of misunderstanding and room for improvement in the transclusion widget and shorthand versions. So being able to make this a little clearer and/or pass additional parameter’s a good outcome and I think your @jeremyruston “parameterised transclusion” will help.

As a result of your @jeremyruston own deep and creative history with tiddlywiki, learning from you about the use of transclusions in the core and the perspective you have is very interesting to me.