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

Rule memory as path source #753

merged 1 commit into from Dec 5, 2015


None yet
1 participant
Copy link

commented Dec 3, 2015

Summary: Use the rule memory to determine the (basic) path for an item rep, to prepare for adding a #write instruction to compilation rules.

Current approach

The item reps get their paths (per snapshot) in the ItemRepRouter. The item rep router finds the appropriate routing rule, and assigns the raw path (e.g. output/index.html), along with the path usable for linking (e.g. /).

The rule memory calculator compiles the item with a “recording executor”, which does nothing but record filter/layout/… invocations.

New approach

The rule memory calculator will determine the (basic) path for an item rep. It will do so by finding the appropriate routing rule for that item and creating an appropriate #snapshot rule action that includes the path of the item rep.

The item rep router is still responsible for converting this basic path (e.g. /foo/index.html into the path for writing to (output/foo/index.html) and the path for linking to (/foo/).

This makes it possible to add a :path argument to #snapshot in rules, so you can now write files from within the compilation rule. For example:

compile '/*.md' do
  filter :kramdown
  snapshot :whatever, path: item.identifier.without_ext + '/index.html'

… as opposed to this:

route '/*.md' do
  item.identifier.without_ext + '/index.html'

compile '/*.md' do
  filter :kramdown

Having to specify a snapshot is annoying, so there will be a convenience method #write:

compile '/*.md' do
  filter :kramdown
  write item.identifier.without_ext + '/index.html'

This approach also helps pushing the rules further away from the core of Nanoc, and the rule memory might become a “processing instruction list”, which could become what Nanoc uses to determine how to process an item rep. With that in place, Nanoc could gain alternatives to the Rules file as a processing instruction source.

@ddfreyne ddfreyne force-pushed the merged-rules branch 9 times, most recently from 85f88dd to db94311 Dec 3, 2015

Use rule memory as source for paths
This also adds a :path option to #snapshot, and adds #write as a
convenience method for the last snapshot.

@ddfreyne ddfreyne force-pushed the merged-rules branch from db94311 to ce1f59d Dec 5, 2015

@ddfreyne ddfreyne added to review and removed status:wip 🔧 labels Dec 5, 2015

@ddfreyne ddfreyne added this to the 4.1.0 milestone Dec 5, 2015


This comment has been minimized.

Copy link
Member Author

commented Dec 5, 2015

There are some FIXMEs and TODOs left, but I’ll tackle those in a separate PR since I believe they relate to issues that currently already exist in master.

ddfreyne added a commit that referenced this pull request Dec 5, 2015

Merge pull request #753 from nanoc/merged-rules
Rule memory as path source

@ddfreyne ddfreyne merged commit 4e4681a into master Dec 5, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed

@ddfreyne ddfreyne deleted the merged-rules branch Dec 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.