|
@@ -39,7 +39,7 @@ generator. Content Types were added in 0.8 as a step towards making
|
39
|
39
|
limitations. Chiefly, the association between Content Types, their
|
40
|
40
|
template, and their inclusion in an INDEX is presently ad-hoc.
|
41
|
41
|
|
42
|
|
-### Current Content Types & Indices
|
|
42
|
+### Current Content Types & Indexes
|
43
|
43
|
|
44
|
44
|
There are 3 INDEX subclasses at present: TAG-INDEX, DATE-INDEX, and
|
45
|
45
|
NUMERIC-INDEX, for grouping content by tags, publishing date, and
|
|
@@ -89,7 +89,7 @@ the objects of that content type by iterating over the objects in an
|
89
|
89
|
appropriate fashion, rendering them, and passing the result to
|
90
|
90
|
`write-page` (which should probably just be renamed to `write-file`).
|
91
|
91
|
|
92
|
|
-After this, `render-indices` and `render-feeds` are called, and an
|
|
92
|
+After this, `render-indexes` and `render-feeds` are called, and an
|
93
|
93
|
'index.html' symlink is created to point to the first reverse
|
94
|
94
|
chronological index.
|
95
|
95
|
|
|
@@ -116,8 +116,8 @@ Unfortunately, this does not solve:
|
116
|
116
|
was installed in the theme package. The plugin would need to do
|
117
|
117
|
this itself or the template would need to be included in 'core'.
|
118
|
118
|
2. More seriously, there is no formal relationship between content
|
119
|
|
- types and indices. Indices include *ALL* objects in the `*content*`
|
120
|
|
- hash table. This may be undesirable and doesn't permit indices
|
|
119
|
+ types and indexes. Indices include *ALL* objects in the `*content*`
|
|
120
|
+ hash table. This may be undesirable and doesn't permit indexes
|
121
|
121
|
dedicated to particular content types.
|
122
|
122
|
|
123
|
123
|
### New Content Type: Shouts!
|
|
@@ -142,7 +142,7 @@ by banging on the config or specify the path in its `enable` options.
|
142
|
142
|
### Incremental Compilation
|
143
|
143
|
|
144
|
144
|
Incremental compilation is doable, even straightforward if you ignore
|
145
|
|
-indices. It is also preferable to building the site in parallel as
|
|
145
|
+indexes. It is also preferable to building the site in parallel as
|
146
|
146
|
avoiding work is better than using more workers. Moreover, being
|
147
|
147
|
able to determine (and expose) what files just changed enables new
|
148
|
148
|
functionality such as plugins that cross-post to tumblr.
|
|
@@ -158,6 +158,6 @@ things the existing deployment model would not work as it involves
|
158
|
158
|
rebuilding the entire site. In all likelihood we would want to update
|
159
|
159
|
the site 'in-place'. Atomicity of filesystem operations would be a
|
160
|
160
|
reasonable concern. Also, every numbered INDEX would have to be
|
161
|
|
-regenerated along with any tag or month indices matching the
|
|
161
|
+regenerated along with any tag or month indexes matching the
|
162
|
162
|
modified files. If incremental compilation is a goal, simply
|
163
|
|
-disabling the indices may be appropriate for certain users.
|
|
163
|
+disabling the indexes may be appropriate for certain users.
|