nanoc-conref-fs 0.6.8 → 0.6.9

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: 7bcde44bcb03a3aa5c5d0116665b6e66c585e9ba
4
- data.tar.gz: 938fee284ee626a0b69e8be5f678f981f9fd9cb3
3
+ metadata.gz: 58f928b401b32dbe172ff593c8d10d6931978e66
4
+ data.tar.gz: b9972a4724904bb445cd596e99f2ba4c454565bf
5
5
  SHA512:
6
- metadata.gz: fa5951734f46c06390325d59fcb6b15b68505a2ee4be2fb61397204ad3cf79ea8216c0edc5fa65ae39f642cc3dd08a5f90750e2611223665b83097f6d629c0dc
7
- data.tar.gz: 3728dddfcc8c16c2f1f96cc9698d1deaf2eccbd28577b7da55db00a739e7127cb7b6fab117895275e28b8abb0b6a771031c203ac4d6a4028e75548a10cd50182
6
+ metadata.gz: a3872c011533ec5d6b10a3d5eea7c2370d357ad064c7edb7c80d78e1d015ed59e8329c8eef2e89292991c85b30d994fba0b9f10585d3aea5450efdd87f701cbd
7
+ data.tar.gz: f4759a8fc5b0f0e36e9a2089c1f834d92ae1c28cd6e664e26ce0aee3c37fe3d0fecbfa3b4d660be95bedb6c0bdeb0019027aea3317bf5501f282fd40f34921d2
data/.travis.yml CHANGED
@@ -1,6 +1,6 @@
1
1
  language: ruby
2
2
  rvm:
3
- - 2.2
3
+ - 2.3
4
4
  env:
5
5
  global:
6
6
  - NOKOGIRI_USE_SYSTEM_LIBRARIES=true
data/README.md CHANGED
@@ -1,14 +1,15 @@
1
+ [![Build Status](https://travis-ci.org/gjtorikian/nanoc-conref-fs.svg)](https://travis-ci.org/gjtorikian/nanoc-conref-fs)
1
2
  # nanoc-conref-fs
2
3
 
3
4
  This gem adds a new Filesystem type to Nanoc called `ConrefFS`. This filesystem permits you to use reusable content and Liquid variables in your content to generate multiple outputs from a single source. It makes heavy use of item representations (or `rep`s for short).
4
5
 
5
6
  The idea is that you have a set of YAML files in a data folder which act as your reusables. You can apply these reusables throughout your content.
6
7
 
7
- [![Build Status](https://travis-ci.org/gjtorikian/nanoc-conref-fs.svg)](https://travis-ci.org/gjtorikian/nanoc-conref-fs)
8
+ ## Setup
8
9
 
9
10
  To get started, set the data source in your *nanoc.yaml* file:
10
11
 
11
- ``` yml
12
+ ``` yaml
12
13
  data_sources:
13
14
  -
14
15
  type: conref-fs
@@ -16,7 +17,7 @@ data_sources:
16
17
 
17
18
  You'll probably also want to provide a list of `rep`s which define all the item reps available to your site. For example:
18
19
 
19
- ``` yml
20
+ ``` yaml
20
21
  data_sources:
21
22
  -
22
23
  type: conref-fs
@@ -27,11 +28,29 @@ data_sources:
27
28
 
28
29
  At this point, you'll want to make a couple of changes to your *Rules* file:
29
30
 
30
- * In the `preprocess` block, add a line that looks like this: `ConrefFS.apply_attributes(@config, item, :default)`. This will transform Liquid variables in frontmatter, and add the `:parents` and `:children` attributes to your items (see below).
31
+ * In the `preprocess` block, add a line that looks like this: `ConrefFS.apply_attributes(@config, item, :default)`. This will transform Liquid variables in frontmatter, and add the `:parents` and `:children` attributes to your items [(see below)](#associating-files-with-data).
32
+
33
+ ```yaml
34
+ preprocess do
35
+ @items.each do |item|
36
+ ConrefFS.apply_attributes(@config, item, :default)
37
+ end
38
+ end
39
+
40
+ ```
31
41
 
32
42
  * Add `filter :'conref-fs-filter'` to any of your `compile` Rules to have them render through the conref processor, converting Liquid variables into the actual YAML text.
33
43
 
34
- **NOTE:** If you use this library with Nanoc's ERB filter, and want to use `render`, you'll need to monkey-patch an alias to avoid conflicts with Liquid:
44
+ ```yaml
45
+ compile '/**/*.html' do
46
+ filter :'conref-fs-filter'
47
+ filter :erb # If using erb you will need the monkey patch mentioned below.
48
+ layout '/default.*'
49
+ end
50
+ ```
51
+
52
+ #### Using Erb and Liquid
53
+ If you use this library with Nanoc's ERB filter, and want to use `render`, you'll need to monkey-patch an alias to avoid conflicts with Liquid:
35
54
 
36
55
  ``` ruby
37
56
  require 'nanoc-conref-fs'
@@ -46,11 +65,11 @@ end
46
65
 
47
66
  Then, you can use `renderp` just as you would with `render`.
48
67
 
49
- ## Usage
68
+ ## Defining Variables For Templates
50
69
 
51
- Nearly all the usage of this gem relies on a *data* folder, sibling to your *content* and *layouts* folders. See [the test fixture](test/fixtures/data) for an example. You can change this with the `data_dir` config option:
70
+ The variables exposed to your templates follow certain conventions. By default Nanoc Conref FS sources all its variables from a *./data/* folder, sibling to your *content* and *layouts* folders. See [the test fixture](test/fixtures/data) for an example. You can change the default folder with the `data_dir` config option:
52
71
 
53
- ``` yml
72
+ ``` yaml
54
73
  data_sources:
55
74
  -
56
75
  type: conref-fs
@@ -60,13 +79,91 @@ data_sources:
60
79
  - :X
61
80
  ```
62
81
 
63
- Then, you can [construct a data folder filled with YAML files](https://github.com/gjtorikian/nanoc-conref-fs/tree/master/test/fixtures/data). These act as the source of your reusable content.
82
+ The *./data/* folder should contain [yaml files](https://github.com/gjtorikian/nanoc-conref-fs/tree/master/test/fixtures/data) that organize your variables. These yaml files are the source of your reusable content. Nanoc Conref FS will use your file structure to organize the variables meaning your file names and layout will affect the variable names in the templates.
83
+
84
+ ### Using Variables in Templates
85
+
86
+ Now that you have variables defined in data files how do you use them? There are a couple ways variables are bound. The first and simpliest verison is often used for reusable content.
87
+
88
+ As an example moving fowards lets say we have the following directory structure
89
+
90
+ ```
91
+ data/
92
+ |-> reusables/
93
+ | |-> names.yml
94
+ |-> Categories
95
+ | |-> simple.yml
96
+
97
+ ```
98
+
99
+ For the first example lets use this sample content:
64
100
 
65
- Finally, you'll need some relevant keys added to your *nanoc.yaml* file.
101
+ *data/reusables/names.yml*
102
+
103
+ ```yaml
104
+ first: 'Cory'
105
+ last: 'Gwin'
106
+
107
+ ```
108
+
109
+ Nanoc Conref FS exposes these simple variables to you using liquid. The variables will be bound to the `site.data` namespace. The variables will be name spaced to `site.data.foldername.filename.variable`.
110
+
111
+ ```html
112
+ <p>{{ site.data.reusables.names.first }}</p>
113
+ <p>{{ site.data.reusables.names.last }}</p>
114
+ ```
115
+
116
+ You can also bind a more complex data_association to the page conditionally. This is often used for building navigation structures.
117
+
118
+ Lets use this content:
119
+
120
+ *data/categories/simple.yml*
121
+
122
+ ```yaml
123
+ - Creating a new organization account:
124
+ - About organizations
125
+ - Creating a new organization from scratch
126
+ - Create A Repo:
127
+ - Oh wow
128
+ - I am a child.
129
+ ```
130
+
131
+ In the above structure `- Creating a new organization account:` will be a specific page in our navigation structure, with 2 children. We want to create a template that knows about the current pages sub-pages.
132
+
133
+ The first step in getting this to work is to setup your page variables with a data association. We have not talked about page variable yet, but this is a method of binding more complex variables to specific pages.
134
+
135
+ First we need to configure the page variables in *nanoc.yml*
136
+
137
+ ```yaml
138
+ page_variables:
139
+ -
140
+ scope:
141
+ path: 'test-data'
142
+ values:
143
+ page_version: 'test association'
144
+ data_association: 'categories.simple'
145
+ ```
146
+
147
+ Lets parse the above setting. `page_variable` is just a convention to start the page variable settings. `scope -> path` is the file path to apply these values to. `values` are variables to apply to the page. In the above example `page_version` will be exposed as a simple liquid tag, string. The `data_association` setting has special properties that we will now discuss.
148
+
149
+ The data_association will use a combination of the `title` in the front matter and the yaml configs to determine a `children` and `parent` map to expose to your template via the `item`. Lets check it out.
150
+
151
+ ```html
152
+ ---
153
+ title: Create A Repo <- used as the parent of the data_association
154
+ intro: {{ site.data.reusables.names.first_name }} #<- will output Cory
155
+ ---
156
+ <p><%= @item[:data_association] %> <- this is a string represenation of the data_association "categories.simple"</p>
157
+ <p>
158
+ <%= @item[:children] %> <- ["Oh wow", "I am a child."] These are the children of the `Create Repo` category in categories/simple.yml
159
+ </p>
160
+
161
+
162
+ ```
66
163
 
67
164
  ### Data folder variables
68
165
 
69
- The `data_variables` key applies additional/dynamic values to your data files, based on their path. For example, the following `data_variables` configuration adds a `version` attribute to every data file, whose value is `dotcom`:
166
+ The `data_variables` key applies additional/dynamic values to your data files, based on their path, before the variables are applied to the page. For example, the following `data_variables` configuration adds a `version` attribute to every data file, whose value is `dotcom`:
70
167
 
71
168
  ``` yaml
72
169
  data_variables:
@@ -79,7 +176,7 @@ The `data_variables` key applies additional/dynamic values to your data files, b
79
176
 
80
177
  You could add to this key to indicate that any data file called *changed* instead has a version of `something_different`:
81
178
 
82
- ``` yaml
179
+ ```yaml
83
180
  data_variables:
84
181
  -
85
182
  scope:
@@ -135,12 +232,6 @@ In this case, every file path will get a `version` of `dotcom`, but any file mat
135
232
 
136
233
  See the tests for further usage of these conditionals. In both cases, `path` is converted into a Ruby regular expression before being matched against a filename.
137
234
 
138
- ### Associating files with data
139
-
140
- If you have a special `data_association` value in your `scope`, additional metadata to items will be applied:
141
-
142
- * An attribute called `:parents`, which adds the parent "map topic" to an item.
143
- * An attribute called `:children`, which adds any children of a "map topic."
144
235
 
145
236
  ### Retrieving variables
146
237
 
@@ -3,7 +3,7 @@ $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
3
3
 
4
4
  Gem::Specification.new do |spec|
5
5
  spec.name = 'nanoc-conref-fs'
6
- spec.version = '0.6.8'
6
+ spec.version = '0.6.9'
7
7
  spec.authors = ['Garen Torikian']
8
8
  spec.email = ['gjtorikian@gmail.com']
9
9
  spec.summary = 'A Nanoc filesystem to permit using conrefs/reusables in your content.'
data/test/test_helper.rb CHANGED
@@ -1,3 +1,6 @@
1
+ # silence ruby warnings from nanoc, liquid, etc
2
+ $VERBOSE = nil
3
+
1
4
  require 'bundler/setup'
2
5
  require 'nanoc'
3
6
  require_relative '../lib/nanoc-conref-fs'
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: nanoc-conref-fs
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.6.8
4
+ version: 0.6.9
5
5
  platform: ruby
6
6
  authors:
7
7
  - Garen Torikian
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2017-04-23 00:00:00.000000000 Z
11
+ date: 2017-07-17 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: nanoc
@@ -202,7 +202,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
202
202
  version: '0'
203
203
  requirements: []
204
204
  rubyforge_project:
205
- rubygems_version: 2.6.8
205
+ rubygems_version: 2.6.12
206
206
  signing_key:
207
207
  specification_version: 4
208
208
  summary: A Nanoc filesystem to permit using conrefs/reusables in your content.