Special case for aliases in templates

[twMat]

There is currently no alias feature in the core, but there are recurring requests for it.

The following proposal concerns the particular case of using aliases in templates. I'm thinking that the restricted environment for templates, e.g inside a {{{filtered transclusion}}}, might simplify implementing a special, yet very useful, use case for aliases. (And, who knows, maybe it could serve as a bridge for a general implementation of aliases.)

If I understand it right, a main reason for not including "end user templates" in the core is because the end users assumed "friendly titles requirement" conflict with the shadow tid naming conventions. Still, it would be very useful to be able to do e.g:

{{{ should-not-be-linkified || textify }}}

i.e to apply a core defined template via a user friendly name - an alias - like "textify".

Regardless of implementation, there is need to match the aliases to tiddlers. Here are two ideas for this, a manual mapping and a special marker to flag to the system that a string is an alias:

Manual mapping - declarations and precedence
For declaring an alias, there can be two parallel methods - actually somewhat comparable to how items can appear in lists by either being included from some attribute such as a tag, or from a local list-before field:

1. A central list that maps a tiddler with an alias (multiple aliases?). A central list allows creating aliases without touching (overwriting) the targeted tiddler.
2. A local alias field in the tiddler.

Here comes the special part: If there is a real tiddler titled like the alias then this would take precedence! (Compare this to how real tids overwrite shadow tids.) The order of precedence (from stronger to weaker) would be

1. tiddler
2. alias field
3. central alias list

Special marker
To reduce the risk of someone unknowingly titling a tiddler like an alias, an alias call could require some marker, for example a prefixing ... or even alias: (must still be simple enough to type). Such a prefix could also signify that a certain fallback path is to be used, e.g $:/core/Template/. I guess the precedence could be anywhere in positions 2, 3 or 4.

Such a $:/core/Template/ prefix would make for yet an "entry" for creating custom templates that are accessible via aliases, i.e just create a tiddler titled $:/core/Template/mytemplate, and mytemplate is enough to invoke the template. And it would be simple enough to share templates with one another and add new templates to the core.

Thoughs?

[pmario]

I think the main problem with "core" aliases is performance. Accessing a tiddler by name is only 1 memory "lookup" ... The internal tiddler store is an object that is defined like so:

tiddlers = {
    "tiddler A": {
        fields:{
            title: "tiddler A,
            tags: ["tagA", "tagB"],
            myField: "some text",
            list: "x y z [[tiddler with spaces]]",
            modified: 123435345,
            created: 123435345,
            .... and so on.
        }
    }, 
    "tiddlerB": {
        fields:{
            title: "tiddlerB,
            text: "some text"
        }
    }, 
}

As you can see, the tiddler title eg: "tiddlerB" is there 2 times. ... This makes it easy and extremely fast to "lookup a tiddler by name"
eg: var tidX = tiddlers["tiddlerB"] will write the whole object of tiddlerB to the variable tidX with 1 object-element access.

 tidX = {
        fields:{
            title: "tiddlerB,
            text: "some text"
        }
    }

Since accessing object elements is highly optimized by the js-compiler, accessing a tiddler by name like this is probably the fastest "memory" access that we can create with javascript.

That's also the main reason, why tiddler titles have to be unique, because object element names have to be unique in JS.

From the structure above, you can see, that adding an alias field to the tiddler.fields requires a mechanism, that needs to read every tiddler and store the aliases in a separate index, to make the access fast. .. That's what I'm doing with my uni-link plugin and the aliases index.

There are 3 lookup indexes, that are part of the core atm: (all of them need additional memory)

• backlinks
• tags
• fields

So we "trade" memory consumption for lookup performance. But even if we have an index we still need 2 or more lookups instead of 1 to get a tiddler object.

• The first lookup is "check the index for the tiddler name"
• The second is: "access the store by name"

So we end up with 2 memory access actions, in a program code that is very low level and executed very often. Adding extra code at this level, can make a big difference. ... The same is true for removing code.

Since a TW page is built with "tagged lists" of templates, the core already has a lot to do, to build the lists. We really need to take care, if we add extra code for looking up template aliases. ...

hope that helps to make the underlying mechanisms clearer.

I think it's not that we don't want to have aliases. I think it's the additional complexity that will be needed to make it performant and consistent.

[twMat]

@pmario - thank you very much for your profound explanation! It does give me a better understanding but my ideas only require the extra lookups when the template is called for, so how can this be a performance problem that is bigger than any other function call. Or do I misunderstand? I mean, my idea concerns a delimited "environment" i.e only those places where a template can actually be used, i.e {{...||here}} and {{{...||here}} (possibly also in widget attributes, didn't consider that yet). And the second idea with an indicating prefix to call for a direct substitution (e.g ... really means $:/core/template/) - also in the transclusion context - is even more specific.

It is worth noting that calling for a template doesn't even show a link to the template name. So in a sense, my idea is just about adding functionality to how transclusions with templates are evaluated.

[pmario]

It is worth noting that calling for a template doesn't even show a link to the template name. So in a sense, my idea is just about adding functionality to how transclusions with templates are evaluated.

That's right ... but ... Having no explicit tiddler name is the problem. As I wrote, we have to create a lookup index at startup or by 1st request. Then every time we need an "alias-template" that is called by the alias name we have 2 lookups instead of 1. ... That does double the CPU cycles needed to access the tiddler content.

Transcluding tiddler content is 1 of the widgets, that is used a lot. So adding an extra if() will already slow it down. So the code described above will have the potential to slow down every other transclusion, even if no "alias-template" is requested ...

It's really hard to describe. All of this goes down to the underlying js-code. ...

Every TW widgets inherits the code from here: https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/widgets/widget.js ..

Then the widgets "overwrite" functions, that are different to widget.js

The code we are talking about can be found here: https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/widgets/transclude.js

The code that accesses the tiddler store for transclusions is: this.wiki.parseTextReference(title,field,index,options) The function definition can be found here: https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/wiki.js#L939 ...

As you can see, none of those elements has an idea about an alias-name. ... It's not that simple to find the right position, where to implement the new alias-functions. It has to be generic enough, to work with every edge case, where transclsions can happen and it should be performant.

[Jermolene]

The first thing to note is that people can already make constructions like {{{ should-not-be-linkified || textify }}}, as long as they take care to use a different naming convention for templates vs. ordinary tiddler titles. The core doesn't include any such templates with short names to keep things simple for users who are not using them.

Secondly, @twMat's intuition is correct: supporting aliases in a particular situation such as transclusion templates is a much more limited proposition than full fledged support for generic aliases, and thus easier and less risky to implement.

I would be interested in adding support for short template names, but I wouldn't approach it in quite this way. Instead, I'd favour an alternate transclusion syntax that makes it explicit that a short name is being specified. It would then be prefixed with $:/core/ui/Templates/ before use.

[pmario]

I would be interested in adding support for short template names, but I wouldn't approach it in quite this way. Instead, I'd favour an alternate transclusion syntax that makes it explicit that a short name is being specified. It would then be prefixed with $:/core/ui/Templates/ before use.

I could think about a call like this: {{tiddlerName|~myTemplate}} ... where ~ would be translated to $:/~/ ... So the real tiddler name would be: $:/~/myTemplate

Calling it without a tiddlerName would look like: {{|~myTemplate}} ...

I wouldn't limit it to /core/ui/ ... IMO it should be usable for everyone.

just a thought.

[pmario]

... BUT I personally would like to have a more generic "alias/es" support. ... So we may name the above mechanism differently. ... eg: "short template" or something similar

[Jermolene]

Depending on how we implemented things, we could have a variable tv-short-template-prefix that users could change globally or locally to the prefix of their choice.

[Jermolene]

... BUT I personally would like to have a more generic "alias/es" support. ... So we may name the above mechanism differently. ... eg: "short template" or something similar

"Short template name" would work.

[twMat]

@pmario and @Jermolene , I like where this is pointing.

BTW, could an implementation for this also be used in widget attributes (template="~mytemplate")? Again, this is a delimited context and I guess it could be confusing if it works in {{...}} but not in widgets.

[Jermolene]

@pmario and @Jermolene , I like where this is pointing.

BTW, could an implementation for this also be used in widget attributes (template="~mytemplate")? Again, this is a delimited context and I guess it could be confusing if it works in {{...}} but not in widgets.

My straw man proposal is better thought of as an extended transclusion syntax, not a shortcut syntax that can be used to refer to these template tiddlers in other contexts.

The syntax could be something like {{currentTiddler|>|template}}, so hopefully it wouldn't look like |>|template could be used elsewhere.