Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document use with alternatives #13

Open
nixjdm opened this issue Jun 12, 2018 · 3 comments
Open

document use with alternatives #13

nixjdm opened this issue Jun 12, 2018 · 3 comments

Comments

@nixjdm
Copy link
Member

nixjdm commented Jun 12, 2018

We should document how to use this plugin with alternatives.

See as an example

https://github.com/pybee/pybee.github.io/blob/lektor/configs/atom.ini

https://github.com/pybee/pybee.github.io/blob/lektor/templates/blog.html#L8

@goanpeca
Copy link
Member

I will add the section to the readme

eigengrau added a commit to eigengrau/lektor-atom that referenced this issue Aug 8, 2018
While lektor-atom currently supports creating feed variants by relying on
specially-crafted item query expressions, this is only useful for item model
fields that contain natural language strings. When creating feeds based on
structured data, this is not helpful, since field values are identical across
two alts.

E.g., when we would like to publish a feed based on PDF attachments that have a
`volume_number` set, we are currently unable to have the English feed display
item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German
alternative.

This commit adds support for such use-cases by adding two new mechanisms:

1. Instead of supplying field names to map records to Atom entries, the user
   supplies a Jinja template. These expressions are evaluated with `this` bound
   to the blog resp. the item record.

2. For a feed named `feed`, configuration values are first looked-up in the
   config file section `[feed.ALT]`, where `ALT` is the alternative currently
   being generated. This allows settings defaults in `[feed]`, and overriding
   only those settings that are locale-specific by adding them to `[feed.ALT]`.

As a side-effect, this also benefits users that don’t use alternatives, since it
enables them to compose item titles, bodies, etc. using multiple fields at the
same time.

Fixes lektor#3, lektor#13.
eigengrau added a commit to eigengrau/lektor-atom that referenced this issue Aug 9, 2018
While lektor-atom currently supports creating feed variants by relying on
specially-crafted item query expressions, this is only useful for item model
fields that contain natural language strings. When creating feeds based on
structured data, this is not helpful, since field values are identical across
two alts.

E.g., when we would like to publish a feed based on PDF attachments that have a
`volume_number` set, we are currently unable to have the English feed display
item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German
alternative.

This commit adds support for such use-cases by adding two new mechanisms:

1. Instead of supplying field names to map records to Atom entries, the user
   supplies a Jinja template. These expressions are evaluated with `this` bound
   to the blog resp. the item record.

2. For a feed named `feed`, configuration values are first looked-up in the
   config file section `[feed.ALT]`, where `ALT` is the alternative currently
   being generated. This allows settings defaults in `[feed]`, and overriding
   only those settings that are locale-specific by adding them to `[feed.ALT]`.

As a side-effect, this also benefits users that don’t use alternatives, since it
enables them to compose item titles, bodies, etc. using multiple fields at the
same time.

Fixes lektor#3, lektor#13.
eigengrau added a commit to eigengrau/lektor-atom that referenced this issue Aug 9, 2018
While lektor-atom currently supports creating feed variants by relying on
specially-crafted item query expressions, this is only useful for item model
fields that contain natural language strings. When creating feeds based on
structured data, this is not helpful, since field values are identical across
two alts.

E.g., when we would like to publish a feed based on PDF attachments that have a
`volume_number` set, we are currently unable to have the English feed display
item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German
alternative.

This commit adds support for such use-cases by adding two new mechanisms:

1. Instead of supplying field names to map records to Atom entries, the user
   supplies a Jinja template. These expressions are evaluated with `this` bound
   to the blog resp. the item record.

2. For a feed named `feed`, configuration values are first looked-up in the
   config file section `[feed.ALT]`, where `ALT` is the alternative currently
   being generated. This allows settings defaults in `[feed]`, and overriding
   only those settings that are locale-specific by adding them to `[feed.ALT]`.

As a side-effect, this also benefits users that don’t use alternatives, since it
enables them to compose item titles, bodies, etc. using multiple fields at the
same time.

Fixes lektor#3, lektor#13.
eigengrau added a commit to eigengrau/lektor-atom that referenced this issue Aug 9, 2018
While lektor-atom currently supports creating feed variants by relying on
specially-crafted item query expressions, this is only useful for item model
fields that contain natural language strings. When creating feeds based on
structured data, this is not helpful, since field values are identical across
two alts.

E.g., when we would like to publish a feed based on PDF attachments that have a
`volume_number` set, we are currently unable to have the English feed display
item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German
alternative.

This commit adds support for such use-cases by adding two new mechanisms:

1. Instead of supplying field names to map records to Atom entries, the user
   supplies a Jinja template. These expressions are evaluated with `this` bound
   to the blog resp. the item record.

2. For a feed named `feed`, configuration values are first looked-up in the
   config file section `[feed.ALT]`, where `ALT` is the alternative currently
   being generated. This allows settings defaults in `[feed]`, and overriding
   only those settings that are locale-specific by adding them to `[feed.ALT]`.

As a side-effect, this also benefits users that don’t use alternatives, since it
enables them to compose item titles, bodies, etc. using multiple fields at the
same time.

Fixes lektor#3, lektor#13.
eigengrau added a commit to eigengrau/lektor-atom that referenced this issue Aug 9, 2018
While lektor-atom currently supports creating feed variants by relying on
specially-crafted item query expressions, this is only useful for item model
fields that contain natural language strings. When creating feeds based on
structured data, this is not helpful, since field values are identical across
two alts.

E.g., when we would like to publish a feed based on PDF attachments that have a
`volume_number` set, we are currently unable to have the English feed display
item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German
alternative.

This commit adds support for such use-cases by adding two new mechanisms:

1. Instead of supplying field names to map records to Atom entries, the user
   supplies a Jinja template. These expressions are evaluated with `this` bound
   to the blog resp. the item record.

2. For a feed named `feed`, configuration values are first looked-up in the
   config file section `[feed.ALT]`, where `ALT` is the alternative currently
   being generated. This allows settings defaults in `[feed]`, and overriding
   only those settings that are locale-specific by adding them to `[feed.ALT]`.

As a side-effect, this also benefits users that don’t use alternatives, since it
enables them to compose item titles, bodies, etc. using multiple fields at the
same time.

Fixes lektor#3, lektor#13.
@webknjaz
Copy link

Did this ever get implemented in master? I see there's eigengrau@ad6502f in a fork but it seems like lektor-atom still doesn't support alternatives...

@webknjaz
Copy link

Aha! So the PR is #16. That looks stale...

jcharaoui pushed a commit to jcharaoui/lektor-atom that referenced this issue Oct 20, 2021
While lektor-atom currently supports creating feed variants by relying on
specially-crafted item query expressions, this is only useful for item model
fields that contain natural language strings. When creating feeds based on
structured data, this is not helpful, since field values are identical across
two alts.

E.g., when we would like to publish a feed based on PDF attachments that have a
`volume_number` set, we are currently unable to have the English feed display
item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German
alternative.

This commit adds support for such use-cases by adding two new mechanisms:

1. Instead of supplying field names to map records to Atom entries, the user
   supplies a Jinja template. These expressions are evaluated with `this` bound
   to the blog resp. the item record.

2. For a feed named `feed`, configuration values are first looked-up in the
   config file section `[feed.ALT]`, where `ALT` is the alternative currently
   being generated. This allows settings defaults in `[feed]`, and overriding
   only those settings that are locale-specific by adding them to `[feed.ALT]`.

As a side-effect, this also benefits users that don’t use alternatives, since it
enables them to compose item titles, bodies, etc. using multiple fields at the
same time.

Fixes lektor#3, lektor#13.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants