Link to url from Tiddlywiki contents menu

#1

Folks,

Returning to TiddlyWiki design after a break, I realised once again I would really like to add items to the standard TOC that are links to external sites. To keep this simple here is how I think it may be done and would like to know if someone has already done this.

Tiddlers with a url field get listed in the contents with their title however on clicking will open in a new tab the url.

Design approach:

Redefine the core link widget (use GenesisWidget) such that

  • if the target tiddler contains the url field generate a html link to that url fields value
  • while using the title/caption for the pretty link.
  • perhaps also present a link icon (toggle on off) with descriptive mouse over tooltip
  • Otherwise behave as per normal.

This method allows the behavior to extend to every use of standard links in a wiki that include the url field.

My back story

I have being offline for a while and not contributing to the TiddlyWiki community, first time in more than 10 years really. What have I being doing? Newly retired I have being spending time on my bush property, and house sitting around my Australian state of New South Wales. I have also being making friends, socialising and dating. This resulted in a new girlfriend which is great.

3 Likes
#2

I do like the idea of being able to use an external url for the to value in the $link widget, there’s lots of cases where I’ve wanted to dynamically create an external url, but I wouldn’t want it to automatically use a url field.

I’m not familiar with the genesis widget, so my approach would be to modify the toc macro either locally or in $:/core/macros/toc

One approach might be modify toc-body and replace

          <li class=<<toc-item-class>>>
            <$list filter="[all[current]toc-link[no]]" emptyMessage="<$link to={{{ [<currentTiddler>get[target]else<currentTiddler>] }}}><<toc-caption>></$link>">
              <<toc-caption>>
            </$list>
            <$macrocall $name="toc-body" tag=<<item>> sort=<<__sort__>> itemClassFilter=<<__itemClassFilter__>> exclude=<<excluded>> path=<<path>>/>
          </li>

with something like

<%if     [all[current]toc-link[no]]    %>
    <<toc-caption>>
<%elseif [<currentTiddler>get[toc-url]]   %>
    <a href={{{ [<currentTiddler>get[toc-url]] }}} ><<toc-caption>></a>
<%else%>
    <$link to={{{ [<currentTiddler>get[target]else<currentTiddler>] }}}><<toc-caption>></$link>
<%endif%>
#3

hmmmm, Just my thoughts,

I am working with a wiki. IMO internal links should open internal tiddlers, that contain information, that is stored locally.

If it is necessary to send the user to a 3rd party site, that external link should use the existing external link syntax as described at: https://tiddlywiki.com/#Linking%20in%20WikiText

I personally do not want to send users away from my site. I intend to keep them as long as possible. Only if there is no other way I send them away.

The advantage here is, that my wiki needs to contain enough information that it makes sense in the context I want to provide.

An other advantage is that having enough information in my own wiki, it prevents information loss because of 3rs party link rot

As I wrote — Just my thoughts.

#4

I like this general idea. But I would argue against using url as the field name here. I think it should be something less likely to interfere with users’ current practice. I think it should start with an underscore, the way that _canonical_uri does. It would be useful if that were a convention for properties that the core might take advantage of. Perhaps _url_to_load or something else reasonably obscure.

I don’t share that sentiment at all. Sure, I want my sites to contain plenty of useful information. But I can’t hold everything that might be of interest. If I can link to something useful, all the better.

In fact, I have several wikis for my day job that are little more than organized collections of links. Each of them tries to gather 10 - 20 years of documentation for large systems. While I do a small bit of synthesis, they mostly collects links to Confluence, Sharepoint, GitHub Pages, GitLab Pages, and file shares. (And in fact, most of these tiddlers have url fields, but used somewhat differently than as suggested here.)

2 Likes
#5

Thanks Scott and @pmario I also realise as we perhaps do with any such solution a default fieldname may activate this function but it should be configurable, dare I say even a list field allowing multiple field names to be given.

@pmario Scott has explained my view on this nicely. Remember this will be a feature someone has to choose, and there is no reason why we can’t permit a method such as ctrl-click that will open the tiddler rather than follow the link. My intention is to open in new tab, so the wiki remains open.

I also think the fact it is an external link should be indicated eg blue underline or an icon that provides information on mouse over. The key here is allowing any link in the wiki that exists in a tiddler with the nominated field but only these links.

However like your example Mario I would avoid links away on a website for naive users, but use them thoroughly on my own wikis and resource websites. I would call these one click external links.

May be I should use a more descriptive field name by default such as _external_link, then provide some features to bring this forward when tiddlers are in the story, search tool within tiddlers containing the fieldname, and list items.

To be investigated;
What if one could have N external links in one tiddler, thus a drop down to select a specific one or the original tiddler. This will then be a two click solution.

#6

I do have such a need. When I see an article worth collecting, I usually save it to my own TiddlyWiki, so I usually save an online link URL field, which I put on the subtitle to display it for easy click.

image
image2067×1074 152 KB