Expose current page source file extension to layout

[edrex]

I'm porting a Jekyll blog to Harp, and one feature of the current site which I don't think is possible to do with Harp currently is the edit this page link, which goes to the source file in a web based editing interface (eg github or prose.io).

current.path gives me everything but the source extension.

Any chance the source extension could be included in current somewhere? I recognize this breaks the abstraction somewhat, but I think that edit link is pretty useful.

[edrex]

I don't think this is a documentation issue. It's a feature request for exposing the source filename via locals.current. Right now current contains an array of strings called path, which contains all needed information except the source extension.

The motivation for this feature request is to enable referencing the source file in the page output. I used this on my previous blog to provide generic "edit" and "view source" links, but this is not possible with Harp currently.

This would be a simple change to make, but I would want to get support from the core team for a particular change in the interface before submitting a pull request. Suggestions:

• Add current.sourcePath, exposing the full path of the source file relative to the public directory.
• Add current.sourceExtension which, coupled with current.path, could be used to reconstruct the source path.

[kennethormandy]

Thanks for following up on this.

We had talked about current.base providing the relative path. I think current.base + current.source could be the same as what you’re suggesting for current.sourcePath, and provide more flexibility for the GitHub Pages use case. Then you properly create relative references, too:

link(href="#{current.base}css/application.css" type="text/css" rel="stylesheet")

which wouldn’t render as anything in the root, and would render as ../ in one directory in, for example. This would close #47 which would be great.

For the extension, we had been suggesting you hard code these in if you need them since it’s related to your directory structure and to using harp compile. That was why I originally marked it docs, but then I dug into your site a little and saw why that wouldn’t help you.

I do think it could be worthwhile, but not as part of current. It occurs to me that this might be possible already by using _contents and splitting on the first . from the end of the string. Nevermind that part, I was thinking about the output, not the input.

What do you think, @sintaxi?

[edrex]

I think the discussion in #47 is about providing the site's base URL path as a global, so that eg you could deploy to http://myhost.com/mysite/. This is different from what I am asking for, which is a way to find out the source filename of the current page relative to the public directory.

Are you suggesting that I should hard code the source file extension in the metadata for each document? That seems error prone given that the information is available at compile time.

[kennethormandy]

Yeah, sorry, my whole comment is pretty much a write off. I was thinking about the output rather than the input.

I do think _current would be the wrong place for it, though, as you might want to iterate over that information.

[remy]

Following up on this too. I'd like to see the current.source actually show the source filename, not just the basename (though I'm unsure what use the basename is since we have the same value appearing at the end of the current.path array).

I'm after the source filename for the exact same reason, so that I can dynamically link up my rendered pages to a github repo to allow viewers to edit (or at least point them that way).

(I also suspect, though through checking - can't quite be sure - that this might be in terraform rather than this project).

[edrex]

@remy yeah, the change would be around https://github.com/sintaxi/terraform/blob/master/lib/helpers/raw.js#L286

[remy]

@sintaxi would you be open to a PR against terraform to change this? Though I suspect it'll also require a change to a lot of the tests I've run across too. Equally, I'm not sure of the wider impact of this change - which might suggest a new property would make more sense?

[kennethormandy]

I know @silentrob and I both came across more cases where we’d like to see this. I don’t think adding this would necessarily break anything in use now, getting the API right probably be the most difficult part.

_contents lets you work with the compiled tree, so I think it would be good to have something akin to that, for the source files. I had cases where I wanted to iterate over Jade partials, for example.