1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
Hi,
I am trying to build a template. The compilation of this template results in a weird exception. I have isolated the cause of the exception to the following point:
If i have this in the template code:
\[[!inline<br/>
pages="\<TMPL_VAR SEL_PAGES\>"<br/>
template=extract-entry<br/>
\]]<br/>
There is no problem at all. I can use the template with the desired result. But if I try to use this (just adding the "show" parameter):
\[[!inline <br/>
pages="\<TMPL_VAR SEL_PAGES>"<br/>
template=extract-entry<br/>
show=\<TMPL_VAR CNTPG><br/>
\]]<br/>
I get this exception on the Git bash console:
<pre>
$ git push
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 410 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: From /home/b-odelama-com/source
remote: eb1421e..5e1bac5 master -> origin/master
remote: Argument "\x{3c}\x{54}..." isn't numeric in numeric lt (<) at /usr/share/perl5/IkiWiki/Plugin/inline.pm line 231.
remote: Argument "\x{3c}\x{54}..." isn't numeric in numeric lt (<) at /usr/share/perl5/IkiWiki/Plugin/inline.pm line 231.
To ssh://b-odelama-com@odelama-com.branchable.com/
eb1421e..5e1bac5 master -> master
</pre>
Please, let me know what to do to avoid this kind of error.
> When you add a template page `templates/foo.mdwn` for use
> the [[ikiwiki/directive/template]] directive, two things happen:
>
> 1. `\[[!template id=foo ...]]` becomes available;
> 2. a wiki page `templates/foo` is built, resulting in a HTML file,
> typically `templates/foo/index.html`
>
> The warnings you're seeing are the second of these: when ikiwiki
> tries to process `templates/foo.mdwn` as an ordinary page, without
> interpreting the `<TMPL_VAR>` directives, `inline` receives invalid
> input.
>
> This is a bit of a design flaw in [[plugins/template]] and
> [[plugins/edittemplate]], I think - ideally it would be possible to
> avoid parts of the page being interpreted when the page is being
> rendered normally rather than being used as a template.
>
> There *is* a trick to avoid parts of the page being interpreted when
> the page is being used as a template, while having them appear
> when it's rendered as a page:
>
> <TMPL_IF FALSE>
> <!-- This part only appears when being used as a page.
> It assumes that you never set FALSE to a true value :-) -->
> \[[!meta robots="noindex,nofollow"]]
> This template is used to describe a thing. Parameters:
> * name: the name of the thing
> * size: the size of the thing
> </TMPL_IF>
>
> The thing is called <TMPL_VAR name> and its size is <TMPL_VAR size>
>
> I suppose you could maybe extend that to something like this:
>
> <TMPL_IF FALSE>
> <!-- This part only appears when being used as a page.
> It assumes that you never set FALSE to a true value :-) -->
> \[[!meta robots="noindex,nofollow"]]
> This template is used to describe a thing. Parameters:
> * name: the name of the thing
> * size: the size of the thing
> </TMPL_IF>
>
> <TMPL_IF FALSE>
> \[[!if test="included() and !included()" then="""
> </TMPL_IF>
> <!-- This part only appears when being used as a template. It also
> assumes that you never set FALSE to a true value, and it
> relies on the [[ikiwiki/pagespec]] "included() and !included()"
> never being true. -->
> The thing is called <TMPL_VAR name> and its size is <TMPL_VAR size>
> <TMPL_IF FALSE>
> """]]
> </TMPL_IF>
>
> but that's far harder than it ought to be!
>
> Perhaps the right solution would be to change how the template plugin
> works, so that templates are expected to contain a new `definetemplate`
> directive:
>
> This template is used to describe a thing. Parameters:
> * name: the name of the thing
> * size: the size of the thing
>
> \[[!definetemplate """
> The thing is called <TMPL_VAR name> and its size is <TMPL_VAR size>
> """]]
>
> with templates not containing a `\[[!definetemplate]]` being treated
> as if the whole text of the page was copied into a `\[[!definetemplate]]`,
> for backwards compatibility?
>
> --[[smcv]]
>> OK, here is a branch implementing what I said. It adds the `definetemplate`
>> directive to [[plugins/goodstuff]] as its last commit.
>>
>> Templates with the current strange semantics will still work, until
>> IkiWiki breaks compatibility.
>>
>> Possible controversies:
>>
>> * Should the `definetemplate` plugin be core, or in goodstuff, or neither?
>>
>> * Should \[[!definetemplate]] be allowed on any page (with the implementation
>> of `template("foo")` looking for a `definetemplate` in `templates/foo`,
>> then a `definetemplate` in `foo`, then fall back to the current logic)?
>> If not, should \[[!definetemplate]] raise an error when used on a page not
>> in `templates/`, since it will have no practical effect there?
>>
>> * Is it OK to rely on `definetemplate` being enabled in the basewiki's
>> templates?
>>
>> * Should the "use definetemplate" wording in the documentation of
>> template and edittemplate be stronger? Should those plugins automatically
>> load definetemplate?
>>
>> --[[smcv]]
>>> this looks like a good idea to me.
>>>
>>> * i'd put it in core, and add a transition for the time compatibility gets
>>> broken, provided the transitioning system will be used in that. templates
>>> can't be expected to just work as markdown+ikiwiki too.
>>>
>>> (it being in core would also solve my qualms about `section => "web"` /
>>> `\[[!tag type/web]]`).
>>>
>>> * if definetemplate gets deemed core, no "use definetemplate!" notes on the
>>> template/edittemplate pages will be required any more.
>>>
>>> * first i was sceptical of the approach of re-running scan to make sure the
>>> `my %templates` is filled, but it is indeed a practical solution.
>>>
>>> * the name "`definetemplate`" gives me the first impression that something
>>> is assigned (as in `#define`), but actually it highlights a region in the
>>> file. wouldn't "`templatebody`" be a better description of the meaning of
>>> the directive?
>>>
>>> --[[chrysn]]
>>>> Thanks for your feedback!
>>>> Looking at its description on this wiki, I agree that `type/web` doesn't
>>>> fit, and core does seem better. I like your `templatebody` suggestion,
>>>> too, particularly if templates remain restricted to `/templates`.
>>>> I'll try to come up with better wording for the documentation to say
>>>> "use `templatebody`, like this", with a note about backwards
>>>> compatibility later.
>>>>
>>>> Rationale for `my %templates`: yes it does seem a bit odd, but
>>>> if I used `$pagestate{$tpage}{template}` instead of a `my` variable,
>>>> I'd sometimes _still_ have to force a `scan`, because
>>>> [[plugins/template]] has to expand the template at scan time so that
>>>> it can contain links etc. - so I have to make sure that if the
>>>> template has changed, it has already been scanned (scanning happens
>>>> in random order, so that can't be guaranteed). This means there's
>>>> no benefit in reading it back from the index, so it might as well
>>>> just be in-memory.
>>>>
>>>> I suppose an alternative way to do it would be to remember what was
>>>> passed to `needsbuild`, and only force a `scan` for templates that
>>>> were in that list - which potentially reduces CPU time and I/O a
>>>> little, in exchange for a bigger index. I could do that if Joey
>>>> wants me to, but I think the current approach is simpler,
>>>> so I'll stick with the current approach if it isn't vetoed.
>>>> --[[smcv]]
>>>>> @name: even outside `/templates`, `\[[!templatebody]]` would be
>>>>> interpreted as "when this page is used as a template, this is what its
>>>>> contents should be", and be suitable.
>>>>>
>>>>> @`%templates`: my surprise wasn't to it not being in `%pagestate`, but
>>>>> rather that the `scan` function was used for it at all, rather than plain
>>>>> directive parsing that ignores everything else -- but i agree that it's
>>>>> the right thing to do in this situation.
>>>>>
>>>>> --[[chrysn]]
>>>>>> [[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
>>>>>> [[!tag patch]]
>>>>>> Branch and directive renamed to `ready/templatebody` as chrysn suggested.
>>>>>> It's on-by-default now (or will be if that branch is merged).
>>>>>> Joey, any chance you could review this?
>>>>>>
>>>>>> There is one known buglet: `template_syntax.t` asserts that the entire
>>>>>> file is a valid HTML::Template, whereas it would ideally be doing the
>>>>>> same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
>>>>>>> Looking over this, I notice it adds a hash containing all scanned
>>>>>>> files. This seems to me to be potentially a scalability problem on
>>>>>>> rebuild of a site with many pages. Ikiwiki already keeps a lot
>>>>>>> of info in memory, and this adds to it, for what is a fairly
>>>>>>> minor reason. It seems to me there should be a way to avoid this. --[[Joey]]
>>>>>>>> Maybe. Are plugins expected to cope with scanning the same
>>>>>>>> page more than once? If so, it's just a tradeoff between
>>>>>>>> "spend more time scanning the template repeatedly" and
>>>>>>>> "spend more memory on avoiding it", and it would be OK to
>>>>>>>> omit that, or reduce it to a set of scanned *templates*
>>>>>>>> (in practice that would mean scanning each template twice
>>>>>>>> in a rebuild). --s
|