Setting Top Level Directory for HTML export

In a tbRef, path related pages refer to selecting the “top level directory” exported paths reference. (See here and here for example.) Which attribute is used to select that directory?

The context: I’ve got an RSS feed that isn’t working. Looking at the output I’ve realized the problem is that ^path(original)^, which I’m using to build the feed urls, is exporting a path to the root of my TBX file. I keep the files for export in a container named “Blog,” so exported urls are in the format https://[domain]/Blog/[genuine url]. On my server, I don’t keep everything in a “Blog” folder, so clicking RSS links currently leads to a 404 page.

Easy solution would be to move folders on the server into a “Blog” folder to match the export. I’m not sure I want to do that. Maybe, but not sure. So I’m looking for an easy way to exclude the container “Blog” from the output of ^path^. The pages in tbRef I referenced above have given me hope…but after digging in the Ref and in an info pane in TBX, I’m still stuck.

Any suggestions or ideas about what I’m missing?

Instead of using ^path, I might write a function fPath(theNote) that computes the effective URL of the note. The use ^value(fPath(this)) rather than ^path.

Thanks. I’ve never looked at functions before, but decided to give it a try. What I came up with is:

function fPath(thisNote){return(eval($HTMLExportFileName(grandparent(thisNote)))+"/"+eval($HTMLExportFileName(parent(thisNote)))+"/"+$HTMLExportPath(thisNote).split("/").at(-1))}

I call the function in the RSS agent’s export template using ^value(fPath(original))^ to complete the url.

The last term in the function is copy-past from a tbRef, the earlier bits are me cobbling things together as best I can. The eval statements work because I was already specifying local $HTMLExportFileName values for the parent and grandparents of the original note.

When HTMLExportFileName is blank, I couldn’t find a way to return the $Name processed for export, eg. “A Note” as “a-note.” Perhaps this isn’t possible. In my case it doesn’t matter: eval() does the job. But I’m curious if I’m missing something obvious.

Thanks for having pointed me in the right (and a new) direction.

This folder is the one set via the Export Inspector’s Export to button. The path is actually stored in TBX’s XML source in the <preferences> section:

In this case export is set to output to the user’s ~/Documents folder. As you can see, the location is not stored in an attribute. The same Inspector button is used to (re-)set the stored export folder.

There is no way to access the preference’s value from within the app, e.g. via action code.

I’ll look at clarifying this in the aTbRef pages cited.

1 Like

Because this is my first stab at working with functions, I’m trying to wrap my head around how they are different from things I already do.

As far as I can tell, calling the function I wrote above in an export template does the same thing that the following export code would do (or at least it produces the same output in my file):

^value($HTMLExportFileName(grandparent(original)))^/^value($HTMLExportFileName(parent(original)))^/^value($HTMLExportPath(original).split("/").at(-1))^

So the question I had this morning was why, if the two produce the same output, I would use the function rather than the export code? Then after some experimenting (and some revision to the function), I realized I could call it in a stamp (or an edict) to populate a $PostURL for notes in my blog file that give me a quicklink to their online version. This started to make some things click.

So at a very basic, more beginner than a beginner’s level, would it be wrong to think that a few of the simplest ways that function differs from action or export code is that functions:

  1. offer a single source for oft-used action code where it can be corrected and revised from that single point but with the changes taking affect everywhere the function is called. (kind of an external css model but for code)
  2. are more concise at the point where they are called and thus make it easier to read and debug otherwise complicated actions and/or exports. (makes actions modular rather than singular, the f(x) + f(y) aspect)
  3. allow the same code to be called in different contexts. (In my case, I’ve realized this function created for export can also be called in a stamp or edict to populate an attribute $PostURL.)

Not really a question, I guess but … I post it in case I’m out in left field.

1 Like

aTbRef articles on ^path^ and ^directory^ are now updated, further the above.

1 Like

Thanks @mwra! I think the explanations are helpful and clear.

1 Like