look into rendering problem with suffix-free source files #130

There is no content yet.

@agmck If this update doesn't fix your problem with suffix-free source files, let me know.

That's terrific, Matthew. Thanks a lot! Pagetrees and the project server also seem to work.

I do want to reiterate the point I made in the group; namely that poly output isn't really useful without a suffix, all files will render to the suffix-free filename.

Perhaps we need to rethink output paths more generally. I think it's too much for a lowly markup file to know about its own output targets, but what about specifying poly-target + output path pairs in the pagetree?

For a source file example.pm —

'(example.pm ((html "example/index.html") (txt "example.txt") (pdf "chapter-one.pdf")))

This would allow us to loosen the unreasonably tight coupling between the structure of the source files and their deployment target. If there's anything I can do, let me know.

That's terrific, Matthew. Thanks a lot! Pagetrees and the project server also seem to work. I do want to reiterate the point I made in the group; namely that poly output isn't really useful without a suffix, all files will render to the suffix-free filename. Perhaps we need to rethink output paths more generally. I think it's too much for a lowly markup file to know about its own output targets, but what about specifying poly-target + output path pairs in the pagetree? For a source file example.pm — `'(example.pm ((html "example/index.html") (txt "example.txt") (pdf "chapter-one.pdf")))` This would allow us to loosen the unreasonably tight coupling between the structure of the source files and their deployment target. If there's anything I can do, let me know.

IIUC, the main issue is that you want to be able to specify arbitrary output names, per source file & per render target.

If so, I think that information should either live a) in the source file itself (similar to(define-meta template ...)) or b) the setup module should support a function that calculates output paths, and that could branch based on current-poly-target. Or both, since they can work together: the rule would be “use the output-path generator function unless there’s an explicit output path specified in the source file.”

poly output isn't really useful without a suffix, all files will render to the suffix-free filename.

Can you clarify why you want to be able to write a poly file without a suffix? The poly suffix is a signal that Pollen needs to handle that source file specially. Of course, the poly suffix itself eventually disappears when it gets swapped for the output suffix.

IIUC, the main issue is that you want to be able to specify arbitrary output names, per source file & per render target. If so, I think that information should either live a) in the source file itself (similar to`(define-meta template ...)`) or b) the `setup` module should support a function that calculates output paths, and that could branch based on `current-poly-target`. Or both, since they can work together: the rule would be “use the output-path generator function unless there’s an explicit output path specified in the source file.” > poly output isn't really useful without a suffix, all files will render to the suffix-free filename. Can you clarify why you want to be able to write a `poly` file without a suffix? The `poly` suffix is a signal that Pollen needs to handle that source file specially. Of course, the `poly` suffix itself eventually disappears when it gets swapped for the output suffix.

IIUC, the main issue is that you want to be able to specify arbitrary output names, per source file & per render target.

Correct. Adding that information as metadata was my first thought as well. But then I asked myself — should a markup file really need to know about its own rendering implementation? Wouldn't it be nice to create a separation where markup files exist purely for content, and project configuration is handled elsewhere? This way large structural changes wouldn't necessitate manually editing all affected markup files.

Just a thought. You've set a precedence with (define-meta template ...) so I can understand any reluctance to change the approach.

Can you clarify why you want to be able to write a poly file without a suffix?

Well in my specific case I'm trying to generate html's without .html extension and have other poly targets be rendered with relevant extension, eg. .pdf and .md (and preferably in their own subdirectory).

> IIUC, the main issue is that you want to be able to specify arbitrary output names, per source file & per render target. Correct. Adding that information as metadata was my first thought as well. But then I asked myself — should a markup file really need to know about its own rendering implementation? Wouldn't it be nice to create a separation where markup files exist purely for content, and project configuration is handled elsewhere? This way large structural changes wouldn't necessitate manually editing all affected markup files. Just a thought. You've set a precedence with `(define-meta template ...)` so I can understand any reluctance to change the approach. > Can you clarify why you want to be able to write a poly file without a suffix? Well in my specific case I'm trying to generate html's without `.html` extension and have other poly targets be rendered _with_ relevant extension, eg. `.pdf` and `.md` (and preferably in their own subdirectory).

Stashing metadata in the pagetree is not a bad idea (I’ve considered it before). It’s more that having made metas (= per-file metadata) and setup (= per-directory metadata), I’d prefer to extend those if possible rather than introduce a new location.

should a markup file really need to know about its own rendering implementation? Wouldn't it be nice to create a separation where markup files exist purely for content, and project configuration is handled elsewhere?

But you can do this already. Suppose the following project is in a directory agmck that's installed as a package:

content/example.pm
html/example/index.html.pm
txt/example.txt.pm
pdf/chapter-one.pdf.pm

The first source file, content/example.pm, can hold the content.

#lang pollen
Here is the content ...

The other source files can require this file and provide its doc and metas. (BTW Pollen’s rendering system doesn’t care what #lang we use, as long as we provide doc and metas). In fact they might all be the same:

#lang racket/base
(require agmck/content/example)
(provide doc metas)

When you point the project server at this directory, you can browse and preview these source files as usual. (With one caveat: because these files have a dependency not visible to the project server, you would want to turn off render caching and compile caching via setup)

This is consistent with two idioms already in Pollen: 1) rely on native Racket abstractions whenever possible (like require and provide) 2) use the filesystem to organize the project.

Still, if that’s unsatisfying, nothing prevents you from making a build script that renders files the way you like (everything you need is exposed through pollen/render).

Stashing metadata in the pagetree is not a bad idea (I’ve considered it before). It’s more that having made `metas` (= per-file metadata) and `setup` (= per-directory metadata), I’d prefer to extend those if possible rather than introduce a new location. > should a markup file really need to know about its own rendering implementation? Wouldn't it be nice to create a separation where markup files exist purely for content, and project configuration is handled elsewhere? But you can do this already. Suppose the following project is in a directory `agmck` that's [installed as a package](http://beautifulracket.com/bf/packaging-our-language.html): ``` content/example.pm html/example/index.html.pm txt/example.txt.pm pdf/chapter-one.pdf.pm ``` The first source file, `content/example.pm`, can hold the content. ``` racket #lang pollen Here is the content ... ``` The other source files can `require` this file and `provide` its `doc` and `metas`. (BTW Pollen’s rendering system doesn’t care what `#lang` we use, as long as we provide `doc` and `metas`). In fact they might all be the same: ``` racket #lang racket/base (require agmck/content/example) (provide doc metas) ``` When you point the project server at this directory, you can browse and preview these source files as usual. (With one caveat: because these files have a dependency not visible to the project server, you would want to turn off render caching and compile caching via `setup`) This is consistent with two idioms already in Pollen: 1) rely on native Racket abstractions whenever possible (like `require` and `provide`) 2) use the filesystem to organize the project. Still, if that’s unsatisfying, nothing prevents you from making a build script that renders files the way you like (everything you need is exposed through `pollen/render`).

Thanks for the detailed explanation. This will improve my workflow tremendously. Funnily enough, I'm already using that approach already to concatenate .css.pm files together, but it hadn't occurred to me to use require and provide in otherwise empty files. I'll experiment and perhaps switch to using pollen/render calls if my directories become excessively littered with these otherwise empty files.

Racket continues to surprise and impress! Feel free to close this ticket and enjoy your Sunday.

Thanks for the detailed explanation. This will improve my workflow tremendously. Funnily enough, I'm already using that approach already to concatenate `.css.pm` files together, but it hadn't occurred to me to use `require` and `provide` in otherwise empty files. I'll experiment and perhaps switch to using `pollen/render` calls if my directories become excessively littered with these otherwise empty files. Racket continues to surprise and impress! Feel free to close this ticket and enjoy your Sunday.

I just pushed a small update so that you even leave out doc or metas from a stub file if you don’t need it, for instance:

#lang racket/base
(require agmck/content/example)
(provide doc)

I just pushed a small update so that you even leave out `doc` or `metas` from a stub file if you don’t need it, for instance: ``` racket #lang racket/base (require agmck/content/example) (provide doc) ```

Labels Milestones

look into rendering problem with suffix-free source files #130