Wanted: simpler support for URLs without extensions
#50
Closed
opened 9 years ago by innermatrix
·
6 comments
Loading…
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Let me just preface everything I say here and for the foreseeable future (I anticipate submitting copious issues over time) that I am very attracted by Pollen's design aesthetic, and that I am hoping it will morph into a more general web publishing tool — and to accomplish that, I think it could use direct support for some publishing features that it currently doesn't support.
And with that, let me get to the first issue I am eyeing: I want to publish a website with extensionless URLs for its pages. Instead of http://example.com/page.html, I want http://example.com/page. Now, this can be accomplished by a variety of server-side configuration options which allow /page.html to be accessed at /page, but the more server-agnostic way of doing this is to generate page/index.html from page.html.pp.
Right now, the only way to accomplish this is to have /page/index.html.pp in my source. I would prefer to have /page.html.pp in my source tree, from which /page/index.html is generated, but this is impossible because pagetree rendering (by means of ->output-path and ->stem-source-path) assumes a particular relationship between source and output paths, and this relationship is not configurable.
So, in terms of end result, what I would like to see is support for pretty URLs.
The way I would like to get there is that I would like to see pagetrees extended to (optionally) specify a (source-path output-path) pair, instead of just a source path or just an output path. This would be useful in other ways — for example, if I want to keep various auxiliary files (like sitemaps and robots files) squirreled away somewhere to avoid clutter in the top level of my source tree, I could use a pagetree like '((robots.txt etc/robots.txt.pp) (sitemap.xml etc/sitemap.xml.pp)).
An interesting idea, but there are some thorny side effects to consider. For instance,
directory-require.rkt
file should the source file rely on?1a.
directory-require.rkt
files seem to me like a source-side abstraction. That is, they participate in transforming an input into an X-expression, and therefore I would expect the source-location one to be used.1b. Contrariwise, relative URLs within a page already refer to output files, by virtue of using
…/page.html
, not…page.html.pp
. So, I see those as an output abstraction, and therefore would expect relative URLs to be output-relative.Thoughts?
Using different conventions for source and output abstractions goes against the grain of the design thus far, which is to unify the two views.
Further on that point, even if you could remap URLs as you suggest in the pagetree files, the project server either a) wouldn’t know about these remappings (making the project server useless) or b) would require some dynamic remapping of URLs (complicated and fiddly).
All of this seems like a lot of trouble simply for the pleasure of having
/page/index.html.pp
, which will work fine, live one directory higher in the source tree as/page.html.pp
.That is a fair point, but since on authoring side one spends a lot of time staring at their source, the pleasure is not insignificant. For example, if many of my source files are named
index.html.pp
then all my editor tabs have identical titles; search results give me a long list of identically named files; etc. Sure, in every one of those contexts there is some way that I can get more information about each file / tab / search hit / etc, but doing so adds friction to authoring workflow.So, even if you want to avoid the whole business of arbitrary source-to-output mappings (and I trust your assessment that that would go against the grain of the design), do you have any other proposals for how I could keep reasonable file names (like
page.html.pp
) while producing pretty URLs (like…/page
) without resorting to server-config gimmicks?Here’s one way to approach the problem.
.htaccess
file that rewrites certain URLs of the formdomain.com/page
todomain.com/page.html
. So first, I would set up the production server with an.htaccess
file, and some simple test files, to verify that works as you expect. (Racket’s web server does not support.htaccess
files.)domain.com/page
todomain.com/page.html
, then it seems fair that your source file would be calleddomain.com/page.html.pmd
(or.pp
or.pm
). During development, this will let you prototype and preview your source files with the project server normally (using the fully-qualified link names likedomain.com/page.html
.raco pollen render ...
to build your site, you can make a tiny build script that puts your rendering into “production mode” and renders your pages so that all internal URLs of the formdomain.com/page.html
come out asdomain.com/page
.parameterize
, which is almost like setting a global variable. So in yourdirectory-require.rkt
you might do this:Then in your build script, you can change the behavior of
make-internal-url
by resetting the parameter:In short, use your dev and build environments in their most idiomatic manner, and then patch over the differences.
PS. I don’t recommend pursuing your original suggestion of mapping
/page.html.pp
to/page/index.html
. I think that kind of directory-hopping will lead to madness.