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
|
After realizing (thanks to
[[Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename]])
that I needed some kind of "parentlinks on steroids", I wrote a new
plugin, called pedigree.
This plugin provides a bunch of loops that one can use in his/her
`HTML::Template`'s to iterate over all or a subset of a page's
parents. Inside these loops, half a dozen variables are made
available, in addition to `PAGE` and `URL` that are already provided
by parentlinks.
Amongst many possibilities, one can e.g. simply use this plugin to
give every parent link a different `class=` attribute, depending
either on its depth in the path leading to the current page, or on its
distance to it.
The code and documentation (including simple and complex usage
examples) are in the 'pedigree' Git branch in this repo:
git://repo.or.cz/ikiwiki/intrigeri.git
Seems there is also a [gitweb](http://repo.or.cz/w/ikiwiki/intrigeri.git).
> Ok, I'll take a look. BTW, could you allow user joey on repo.or.cz
> push access to the main ikiwiki repo you set up there? --[[Joey]]
>> I did not. The main ikiwiki repo on repo.or.cz seems to have been
>> been setup by johannes.schindelin@gmx.de ; mine is what they call
>> a "fork" (but it's not, obviously). -- intrigeri
Any opinions on the idea/design/implementation?
> Seems that there should be a more generic way to do `PEDIGREE_BUT_ROOT`
> and `PEDIGREE_BUT_TWO_OLDEST` (also `is_second_ancestor`,
> `is_grand_mother` etc). One way would be to include in `PEDIGREE`
> a set of values like `depth_1`, `depth_2`, etc. The one corresponding
> to the `absdepth` would be true. This would allow a template like this:
<TMPL_LOOP NAME="PEDIGREE">
<TMPL_IF NAME="depth_1">
</TMPL_ELSE>
<TMPL_IF NAME="depth_2">
</TMPL_ELSE>
<TMPL_VAR PAGE> /* only showing pages 2 levels deep */
</TMPL_IF>
</TMPL_IF>
</TMPL_LOOP>
> The only missing information would be `reldepth`, but in the above
> example the author of that template knows that it's `absdepth - 1`
> (Things would be a lot nicer if `HTML::Template` had equality tests!)
>
> Since this would make it more generic and also fix your one documented
> bug, I can see no reason not to do it. ;-) --[[Joey]]
>> Thanks for your comments. I'll answer soon. (Grrr, I really
>> need to find a way to edit this wiki offline, every minute
>> online costs bucks to me, my old modem gently weeps,
>> and I hate webbrowsers.) -- intrigeri
>>> Well, I maybe didn't get your idea properly; I may be missing
>>> something obvious, but:
>>> * I don't understand how this would replace `is_grand_mother`. As a template
>>> writer, I don't know, given an absolute array index (and this is the only
>>> piece of data your solution gives me), if it will be e.g. the before-last
>>> (how do I say this in correct English?) element of an array whose
>>> (variable) size is unknown to me.
>>> * Knowing that `reldepth`'s value is, in a given loop, always equal to
>>> `absdepth - 1` is of little use to me (as a template writer): how do I use
>>> this piece of information programmatically in my templates, if I want all
>>> links with `reldepth==2` to be given the same style? I guess some bits of
>>> Javascript might do the trick, but if it's getting so complicated, I'll
>>> just style my parentlinks another way.
>>> In my understanding, your suggestion gives us little more than can already
>>> be achieved anyway with `HTML::Template`'s `loop_context_vars` (i.e.
>>> `__first__`, `__last__` and `__counter__`). The only added bonus is doing
>>> custom stuff for an arbitrary element in the loop, chosen by its absolute
>>> depth. Please correct me if needed.
>>> (Intermezzo: in the meantime, to suit my personal real-world needs, I added
>>> a `DISTANCE` loop-variable. Quoting the documentation, it's "thedistance,
>>> expressed in path elements, from the current page to the current path
>>> element; e.g. this is 1 for the current page's mother, 2 for its
>>> grand-mother, etc.".)
>>> Anyway, your comments have made me think of other ways to simplify a bit
>>> this plugin, which admittedly provides too much overlapping functionality.
>>> Bellow is my reasoning.
>>> In one of my own real world examples, my two main use cases are :
>>> * the "full-blown example" provided in the documentation (i.e.
>>> displaying every parent but mother and grand'ma as a group, and giving
>>> every of these two last ones their dedicated div);
>>> * skipping the two oldest parents, and inside what's left, displaying the
>>> three youngest parents (i.e. mother, grand'ma and grand'grand'ma), each
>>> one with a dedicated style;
>>> Both of these can be achieved by combining `PEDIGREE`, `DISTANCE`, and some
>>> CSS tricks to hide some parts of the list. `IS_MOTHER` and
>>> `IS_GRAND_MOTHER`, as well as `PEDIGREE_BUT_TWO_OLDEST`, would be convenient
>>> shortcuts, but I do not formally need them.
>>> So... it seems things can be simplified greatly:
>>> * I initially added `RELDEPTH` for completeness, but I'm not sure anyone
>>> would use it. Let's give it up.
>>> * Once `RELDEPTH` is lost (modulo Git tendencies to preserve history), the
>>> known bug is gone as well, and `PEDIGREE_BUT_ROOT` and
>>> `PEDIGREE_BUT_TWO_OLDEST` are now only convenient shortcuts functions;
>>> they could as well disappear, if you prefer to.
>>> It appears then that I'd be personally happy with the single `PEDIGREE` loop
>>> (renamed to `PARENTLINKS`), providing only `PAGE`, `URL`, `ABSDEPTH` (maybe
>>> renamed to `DEPTH`), and `DISTANCE`. This would make my templates a bit more
>>> complicated to write and read, but would also keep the plugin's code to the
>>> bare minimum. Let's say it is my up-to-date proposal. (Well, if the various
>>> shortcuts don't really annoy you, I'd be glad to keep them ;)
(I'll try never to rebase this branch, but writing this plugin has
been a pretext for me to start learning Git, so...)
To finish with, it seems no plugin bundled with ikiwiki uses the current
parentlinks implementation, so one could event think of moving it from the
core to this plugin (which should then be enabled by default, since the
default templates do use parentlinks ;).
> I think that moving parentlinks out to a plugin is a good idea.
> However, if it's done, I think the plugin should be named parentlinks,
> and should continue to use the same template variables as are used now,
> to avoid needing to change custom templates. Pedigree is a quite nice
> name, but renaming it to parentlinks seems to be the way to go to me.
> --[[Joey]]
>> Agreed. -- intrigeri
>> Just commited a testsuite for this plugin, BTW. It's nearly twice
>> big as the plugin itself, I'm wondering... -- intrigeri
|