~adnano/kiln-discuss

3 2

[kiln] Add content to feed without templating

Details
Message ID
<31054ccd-441b-4623-a34d-61fff585ee1d@www.fastmail.com>
DKIM signature
missing
Download raw message
Hi,

just like Ian in https://lists.sr.ht/~adnano/kiln-discuss/%3Cc66331d8-986f-eca1-1978-6d4ed68cefe3%40ianmjones.com%3E I would like to include the HTML content in my feed.
Using {{ exec "gmnitohtml" .Content | safeHTML }} is very neat and much more flexible than the pre-/postprocess options.

Actually, I got rid of the pre-/postprocess options, because my templates live in the kiln templates folder (it forces a copy of <doctype>, but also allows better customization).
But then the {{ .Content }} of the feed includes this template!

I would rather have access to the non-templated content.

The fix is quite trivial (in dir.go, move the feed generation before the templating code).
This change:
- is a breaking change (however if the template is needed, the user can simply copy/paste it in atom.xml)
- but I think it is more natural. I found having templated .Content quite surprising

@Ian: did you have any issue with this templated content? Could you adapt your code to support this change?
I think copy/pasting this template in atom.xml should be enough, right?
https://git.sr.ht/~ianmjones/ianmjones.com/tree/master/item/templates/_default/page.gmi

My current workaround is to use the "atom.xml" generated for gemini in the HTML atom.xml (with a simple mv dist/gmi/atom.xml dist/html/atom.xml)

Thanks

Olivier
Details
Message ID
<CDUTIPW5UKFG.3QQBP0M3EW1D4@nitro>
In-Reply-To
<31054ccd-441b-4623-a34d-61fff585ee1d@www.fastmail.com> (view parent)
DKIM signature
pass
Download raw message
On Wed Aug 25, 2021 at 2:35 PM EDT, Olivier C wrote:
> Hi,
>
> just like Ian in
> https://lists.sr.ht/~adnano/kiln-discuss/%3Cc66331d8-986f-eca1-1978-6d4ed68cefe3%40ianmjones.com%3E
> I would like to include the HTML content in my feed.
> Using {{ exec "gmnitohtml" .Content | safeHTML }} is very neat and much
> more flexible than the pre-/postprocess options.
>
> Actually, I got rid of the pre-/postprocess options, because my
> templates live in the kiln templates folder (it forces a copy of
> <doctype>, but also allows better customization).

Interesting. I hadn't considered this use case.

> But then the {{ .Content }} of the feed includes this template!
>
> I would rather have access to the non-templated content.
>
> The fix is quite trivial (in dir.go, move the feed generation before the
> templating code).
> This change:
> - is a breaking change (however if the template is needed, the user can
> simply copy/paste it in atom.xml)
> - but I think it is more natural. I found having templated .Content
> quite surprising

I am leaning towards making this change, however it will likely affect
existing kiln sites. Another potential solution would be to expose the
original content in a new variable available to templates. This would
fix your problem without breaking existing sites.
Details
Message ID
<62fb217f-1466-4785-b273-0dca51883443@www.fastmail.com>
In-Reply-To
<CDUTIPW5UKFG.3QQBP0M3EW1D4@nitro> (view parent)
DKIM signature
missing
Download raw message
> Another potential solution would be to expose the
> original content in a new variable available to templates. This would
> fix your problem without breaking existing sites.

I am not fond of having an other variable for the same thing (.Content in the regular templates and .RawContent in the feed template).

Another backward compatible solution would be to deprecate (but still support for now) the [feeds] config and implement a [[tasks.feeds]] entry:

```config.toml
[[tasks]]
input = [".gmi"]
output = ".gmi"
template = ".gmi"
static_dir = "static"
output_dir = "public"

[[tasks.feeds]]
input_dir = "" # like the current permalink, without leading/trailing slash 
title = "Example feed"
template = "atom.xml"
output = "atom.xml"
```

It would be much more flexible than the current map[string]string (which does not allow adding more fields later, like template or output).
Moreover it makes it a task sub-config, so that I can omit it for Gemini, where I don’t need it for instance.
Another benefit is the support of multiple feed types (RSS and atom for example).

I would be willing to make a patch, if you think that this sounds like a good idea (so that we can discuss the naming and implementation details).
Details
Message ID
<CDW3UUW9JD8W.3CHS62CY1D7IO@nitro>
In-Reply-To
<62fb217f-1466-4785-b273-0dca51883443@www.fastmail.com> (view parent)
DKIM signature
pass
Download raw message
On Sun Aug 29, 2021 at 8:42 AM EDT, Olivier C wrote:
> > Another potential solution would be to expose the
> > original content in a new variable available to templates. This would
> > fix your problem without breaking existing sites.
>
> I am not fond of having an other variable for the same thing (.Content
> in the regular templates and .RawContent in the feed template).

I agree that it is not an ideal solution.

> Another backward compatible solution would be to deprecate (but still
> support for now) the [feeds] config and implement a [[tasks.feeds]]
> entry:
>
> ```config.toml
> [[tasks]]
> input = [".gmi"]
> output = ".gmi"
> template = ".gmi"
> static_dir = "static"
> output_dir = "public"
>
> [[tasks.feeds]]
> input_dir = "" # like the current permalink, without leading/trailing slash
> title = "Example feed"
> template = "atom.xml"
> output = "atom.xml"
> ```
>
> It would be much more flexible than the current map[string]string (which
> does not allow adding more fields later, like template or output).
> Moreover it makes it a task sub-config, so that I can omit it for
> Gemini, where I don’t need it for instance.
> Another benefit is the support of multiple feed types (RSS and atom for
> example).
>
> I would be willing to make a patch, if you think that this sounds like a
> good idea (so that we can discuss the naming and implementation
> details).

Hmmm, I actually like this idea. However, the new configuration syntax
needs more thought. One note is that every task needs to specify its own
input = [".gmi"] line or similar, as that preference is implemented
per-task.
Reply to thread Export thread (mbox)