What does mean "its children" in the context of macros/variables import?

#1

In the documentation, I have read the following sentence:

The ImportVariablesWidget imports macro and variable definitions from a list of other tiddlers and makes them available to its children.

What does mean its children in this context?

#2

It is some what over technical, it just means the code inside the ImportVariablesWidget such as macros, widget, and transclusions etc…

That is things within are the children. If it was in the page template most things will have these variables set, in the view template only the current tiddlers etc…

It comes from the way tiddlywiki works and has technical origins in the widget tree and DOM (document object Model)

1 Like
#3

Thx @TW_Tones, this is clear now. So I guess the pragma \import [myFilter] is equivalent to the <$importvariables> encapsulating the whole text field?

Is there a way to chain imports? A import B that import C that defines macros? It is not working for me.

#4

I am not exactly sure what you mean. If rather than widgets you are using pragma such as \define or \import I believe the scope is the current tiddler, unless you made it global by tagging with $:/tags/Macro

Could you give a simple example of what you mean by “chain imports”.

#5

At the moment, it is not possible to import tiddlers that contain further \import pragmas (or <$importvariables> widgets). I have looked at making it work, and found it to be a bit more complex than it first appears. In particular, such support would make it possible to set up recursive loops. So we would need a mechanism to detect that recursion and provide a meaningful message about it to the user.

2 Likes
#6

Thx @jeremyruston, I will work on the import filter instead to grab everything I need.

That would be nice to add into the documentation what the exact equivalent of a widget is when pragma or transclusion form exist.

#7

I also tried without success \import <<import_class_filter>>, import_class_filter defining my filter in a global macro :

\define import_class_filter()
[prefix[$:/fdz/Class/Macro/]]
\end

but I presume you cannot do that… :sweat_smile:

#8

The argument to the \import pragma is a filter expression, so things should work with \import [<import_class_filter>].

#9

I would think that for @TartakOO’s use case, since <import_class_filter> is a macro containing filter syntax, the \import pragma should be:

\import [subfilter<import_class_filter>]
2 Likes
#10

Thanks @EricShulman that’s quite right.

It may also be worth noting that this particular use case could be more readably expressed using the <$importvariables> widget:

<$importvariables filter=<<import_class_filter>>>
...
</$importvariables>
1 Like
#11

Nice! I understand the point of subfilter now.

But why \import <<import_class_filter>> does not work by substituing the exact filter text I would have write in place? There is obviously a step I do not understand in the process.

#12

The \import pragma expects filter syntax.

<<macroname>> is not a filter… but [<macroname>] is a filter.

and for your macro, since it contains filter syntax, you need the [subfilter<macroname>] syntax.

-e

#13

Not really in my case. My goal is:

  • having a shared mechanism to dynamically import all macros (ok now)
  • making the call to the mechanism the shortest and the most explicit possible (both solutions are a bit verbose compared with a pure macro call, so I will keep the pragma that requires just a single line)