Hi Tony,
Just seeing this now. I suspect that if I'd had this as a reference in the
summer, collecting so many gotchas in one place, it would have saved me a
lot of time thinking in circles. Thanks for sharing it!
Best,
Chris
On Wednesday, September 30, 2020 at 10:17:43 PM UTC-4 TonyM wrote:
@Tones
*Just as {{||template}} is not supported as a widget attribute,
> {{{filter||template}}} is not supported for filtered attributes. *
>
> I am not so sure about this statement. I understood the template
> pre-processes the result then delivers the value(s) to the attribute. I
> will look
Saq,
As you are aware the wikification process is linked to the render process.
I am trying to keep this issue focused and fix the gap I have highlighted.
The term I try and use is "evaluate", basically to resolve a value from the
wikitext elements and use it in logic and other tests, ideally
@Tones wiki syntax for transclusions, and syntax for indirect and filtered
attributes for widgets, are two entirely different things and changing them
would not be backwards compatible.
Refer to this thread that explains the same difference but with regards to
double brace transclusions and
Saq,
In effect are you a saying in the latter the reference to the value is the
result rather than the value?, I understand the complexities here (I think)
however I expect 99% of users
- Do not understand this distinction
- Think the value is returned, and expects it in filter logic
An important distinction to make is that between filtered transclusions in
wikitext, and filtered attributes for widgets.
In the former, the {{{ filter || template }}} format is supported because
the output gets wikified.
In the latter, this is not supported as the literal value of the filter
codaCoda,
I have updated the content of "&" to return text only
<$text text={{{ [all[current]split[ ]] +[join[]] }}}/>
*Important guidance* is
- the "filter" given to the transclusion needs each value to be treated
as a title hence
- $:/string/ [] / [{!!fieldname}] [[/suffix/]]
Tony - Looks good on a first pass... I'll need to look at it properly
tomorrow (it's late here).
On Wednesday, December 2, 2020 at 6:59:28 PM UTC-6 TonyM wrote:
> And using codaCodas examples prior;
>
> <$wikify name=style-value text="""color: {{!!color}}""">
> style=<>
>
>
> Check this
And using codaCodas examples prior;
<$wikify name=style-value text="""color: {{!!color}}""">
style=<>
Check this in
devtools
Check this in devtools
Again great for attribute values and parameters, but still need another
step to get the result into a filter.
Tony
Tones
On Thursday,
Saq et al,
Thinking a little further on this issue of "inline concatenation of various
tiddlywiki values", I believe I have just found a quite elegant solution.
Given your complaint about Wikification performance this returns the
"evaluated text"
Create a tiddler called "&" for concatenate
@codacoder There are issues on github discussing both approaches, using
backticks to wikify OR using them to do substitution. I strongly prefer the
latter due to the performance penalty associated with wikify.
See
- https://github.com/Jermolene/TiddlyWiki5/issues/5121
-
Just dreaming out loud...
my span
Note - *backticks*. They become a request for wikification. Of course, they
could be any sensible alternative (though I don't support treading
on/overloading quotes, either ' or " .
And if a substitution run could happen *first*...
>:{{!!field}}`>my span
Yep, it is interesting. I do try to avoid wikify until I prove it's the
only way. In essence, even though the goal is simply stated,
transclusion-filters (to me) seem to cloud the simplicity - leaving a lot
of syntax noise behind. Wikify seems to read simpler, because it's "broken
down" I
@codacoder interesting! While both syntaxes leave a lot to be desired, I
personally find wikify so much uglier.
Personally I use a filter that does something like this:
Check this in devtools
Anyway be warned that depending on the complexity of the contents of the
element you assign a
On Wednesday, December 2, 2020 at 12:40:17 AM UTC-6 saq wrote:
> FYI, the solution using join[] (or addsuffix[]) is *substantially*
> faster...
addsuffix - duh! - Jeez... thanks for the face-palm, Saq!
There's only so long I can stare at something (sometimes, anyway).
--
You received this
Yes. But following along with your thinking was kinda slow. I had to reread
a few times to "get" what you were saying. It was probably me - too tired
at the time.
On Tuesday, December 1, 2020 at 11:11:15 PM UTC-6 TonyM wrote:
> CodaCoda,
>
> Yes I understand that, but I will review the cheat
Agreed. But syntax noise is... well, noisy :/
On Wednesday, December 2, 2020 at 12:40:17 AM UTC-6 saq.i...@gmail.com
wrote:
> FYI, the solution using join[] (or addsuffix[]) is *substantially* faster
> than using wikify to assign widget attributes.
>
> You:
>
> <$wikify name=style-value
FYI, the solution using join[] (or addsuffix[]) is *substantially* faster
than using wikify to assign widget attributes.
You:
<$wikify name=style-value text="""color: {{!!color}}""">
style=<>
Me:
Check this in
devtools
--
You received this message because you are subscribed to the
CodaCoda,
Yes I understand that, but I will review the cheat sheet to see if I give
it sufficient weight.
Did you look at the online
version https://anthonymuscio.github.io/#Standard%20Nomenclature the
filtered transclusions section could promote its use more.
Tony
On Wednesday, 2 December
Hi Tony
Bold effort!
I spotted something in there that I do quite often, but I do it a little
differently:
You:
<$wikify name=style-value text="""color: {{!!color}}""">
style=<>
Me:
Check this in
devtools
Not sure which you might prefer...
On Thursday, October 1, 2020 at 8:13:01
Folks,
This working tiddler is published here;
https://anthonymuscio.github.io/#Standard%20Nomenclature
Regards
Tony
On Thursday, 1 October 2020 12:17:43 UTC+10, TonyM wrote:
>
> Folks,
>
> I have being building a "CheatSheet" that I would appreciate expert review
> if possible. Please
21 matches
Mail list logo
