How do I get ^childLinks^ to link to the original note in an agent?


(Pat Maddox) #1

I’ve got an agent called “all files” with query !$HTMLDontExport. It pulls in all the notes I need. It has an export code using ^childLinks^, which for some reason exports broken links: it creates links to the path where the aliases would be, rather than to the original notes as I would expect.

The agent produces a relative link to all_files/file_1.html (which doesn’t exist), instead of to file_1.html (which is the location of the original note).

I don’t know if this is a bug or not… though I don’t see how it would be expected / desirable behavior.

Anyway, how do people get around this? And @eastgate should this be a bug report?

Here’s an example: broken_agent_links.tbx (57.6 KB)


(Mark Anderson) #2

I think it’s a contextually undesired outcome rather than a bug. ^export^ code was defined when (web/HTML was simpler and before the database driven webpages of Web 2.0. HTML export by concept exports the existing outline as a website of static pages in the same layout. Whilst ^childLinks^ functions as designed, albeit to a different outcome than your desired one, there is a way around this using ^children(template)^. The trick is the template specified exports a list item’s code including a ^linkTo(original)^ code. note that the child notes can still retain their usual export templates. This extra template is used instead of that. Thus the child page might generate just a link via this method but also export itself as a full page (if so required).

So the relevant part of the agent’s template is:

^text^
<ul>
^children("original-links")^
</ul>

Whilst template ‘original-links’ may have code like:

<li>^linkTo(original)^</li>

Indeed, this is exactly the technique my aTbRef TBX uses - see its template “5-agent-link-list”, and is used to create pages like this listing page which is generated from an agent.

If this doesn’t make sense, do ask. :grinning:


(eastgate) #3

As an additional alternative, I’d be willing to entertain the proposition that

^childlinks

should implicitly link the the original notes if $HTMLExportChildren(this) is false. (If your agent were exporting children, the links wouldn’t be broken.)


(Pat Maddox) #4

That seems like an elaborate way of saying “bug” :stuck_out_tongue:

In what context would you desire Tinderbox to create broken links?

Makes sense.

Alternate proposal: ^childLinks^ always links aliases to their original, regardless of $HTMLExportChildren.

Reason: An alias to me represents a pointer. Including an alias in a list of child links, to me, means “link to the thing this alias points to.”

A real child note should produce a page inside the containing note’s subfolder. An alias shouldn’t produce any new pages, and instead simply link to the original (canonical) note location.


(Mark Anderson) #5

Ouch. When I wrote “contextually undesired outcome” I was trying to be polite and non-confrontational. Things work in Tinderbox the way they do. I don’t see this as a bug but simply something that doesn’t work according to someone’s assumptions. We don’t all have the same intuition as to how things work; this doesn’t make anyone ‘wrong’, but some assumptions will match the app design and others won’t. Thus, if I use an export code in a way it’s not designed to work (despite my expectation) in that context the outcome is unexpected - due to my mis-assumptions.

We had discussion of this what-an-alias-is moons ago (c. v4.x?), which led to current function. An alias allows the same note content to be ‘physically’ exported in more than one place. The suggestion above would break that, and lots of current users’ export and, more significantly, make export less flexible. Thus the status quo.

Within Tinderbox, an alias allows one note to be used/seen in multiple contexts. Clicking on an alias doesn’t move context to the original. Rather it shows the original’s data in the current context. Export reflects this. The suggestion above might suit.

I’ve explained (previous post) how to fix the original question. Do please give it a try it before discounting it, given that your suggestion would break current functionality. In addition, I think @eastgate’s suggestion is a reasonable and pragmatic one.


(Pat Maddox) #6

I suppose it depends on what we mean by context then.

If I ^include^ an alias, then I would absolutely expect that content to be exported as a part of the page. That makes sense to me.

Having the same page (original and its aliases) exported to separate, duplicate files on disk? Not so much… but clearly I use this differently from other people.

It does work, thank you. I just won’t use ^childLinks^ from this point on.


(eastgate) #7

Backstagers: there’s a pertinent update on this in b264