On Saturday, January 30, 2016 at 2:31:12 PM UTC-8, Thomas Woite wrote:
> Isn't what I am doing in the inner list (the {{||}} call of the tag
> template a seperate transaclusion for each single tag? Or am I on the wrong
> track here somehow?
>
That seems correct. The transclusion creates a separate branch in the
parse tree, so any <<qualify>> macros it contains will produce a unique
hash value for each tag template that is transcluded by the $list widget.
> Nevertheless I tried to build on Jeremys comment, that the tag template
> in difference to the tab macro does not have the ability to define a custom
> state.
> I tried my own version of the tag template and enhanced the macros with a
> custom state parameter to be passed in, but all I accomplished was, that
> the click on my tags
> did not give any result at all. No popup, nothing.
>
> // my altered version of the tag-body-inner macro
> [...]
>
> \define tag-body-inner(colour,fallbackTarget,colourA,colourB*, state*)
> <$set name="foregroundColor" value=<<contrastcolour target:"""$colour$"""
> fallbackTarget:"""$fallbackTarget$""" colourA:"""$colourA$"""
> colourB:"""$colourB$""">>>
> <$set name="backgroundColor" value="""$colour$""">
> <$button popup=*<<qualify "$state$">>* class="tc-btn-invisible
> tc-tag-label" style=<<tag-styles>>>
> <$transclude tiddler={{!!icon}}/> <$view field="title" format="text" />
> </$button>
> <$reveal state=<<qualify "$:/state/popup/tag">> type="popup"
> position="below" animate="yes"><div class="tc-drop-down"><$transclude
> tiddler="$:/core/ui/ListItemTemplate"/>
> <hr>
> <$list filter="[all[current]tagging[]]"
> template="$:/core/ui/ListItemTemplate"/>
> </div>
> </$reveal>
> </$set>
> </$set>
> \end
> [...]
>
>
>
The problem is that the state="..." param in the $reveal widget *must* be
the same value as the popup="..." param in the corresponding $button
widget. Thus, you need to write:
<$button popup=<<qualify """$state$""">>...
<$reveal state=<<qualify """$state$""">> ...
or perhaps this would be even better:
<$button popup=<<qualify """$:/state/popup/tag/$state$""">>
<$reveal state=<<qualify """$:/state/popup/tag/$state$""">>
Also, note the use of tripled quotes around the parameters. This is
important, because the $state$ value MIGHT contain a double quote since you
are constructing it from a tiddler title, which is allows to have quotes in
it. The triple quotes ensure that any quotes embedded in the value are not
treated as a closing delimiter for the parameter itself.
> The state parameter I am passing in is build in a own macro, concatenated
> from a the tiddler title and the current tag
>
> \define createTag(title, tag)
> <$set name="id" value="$:/state/popup/tag$title$$tag$">
> <$macrocall $name="tag-body" colour={{!!color}} palette={{$:/palette}}
> state=$(id)$/>
> </$set>
> \end
>
>
One small problem here is that you forgot the quotes are $(id)$. Since the
id value MIGHT contains spaces (from the tiddler title), you should write:
... state="""$(id)$"""
Howevr, the much bigger problem here is that you can't use the $(id)$
syntax to insert the value from a variable that was just $set. Macros do
NOT "run" their content and return the output. Rather, then ONLY expand
the $(variable)$ and $param$ references that exist when it is invoked and
then return THAT content for processing in the calling context. Thus, your
macro, when called with <<createTag foo bar>> produces this output:
<$set name="id" value="$:/state/popup/tagfoobar">
<$macrocall $name="tag-body" colour={{!!color}} palette={{$:/palette}}
state=$(id)$/>
</$set>
Note that the $(id)$ syntax remains, because the variable was NOT defined
when the macro was *invoked*.
Fortunately, for this particular use case, there is a proper syntax that
WILL work. Since you are using the variable as a macro param, you can use
<<id>> in place of $(id)$:
\define createTag(title, tag)
<$set name="id" value="$:/state/popup/tag$title$$tag$">
<$macrocall $name="tag-body" colour={{!!color}} palette={{$:/palette}}
state=<<id>>/>
</$set>
\end
Unlike the $(variable)$ expansion that occurs within macros, <<variable>>
references are evaluated whenever they occur in a "wikitext" rendering
context, which includes the processing of widget parameter values. Thus,
unlike $(id)$, using <<id>> DOES retrieve the variable value that was just
$set.
I hope this makes things a bit clearer....
let me know how it goes.
enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
Inside TiddlyWiki: The Missing Manuals
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywiki+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/d33e4093-988d-4319-8399-d5738e241746%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
