]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/todo/matching_different_kinds_of_links.mdwn
Handling non-existing pages in parentlinks.
[git.ikiwiki.info.git] / doc / todo / matching_different_kinds_of_links.mdwn
1 [[!tag wishlist]]
3 As noted in [[todo/tag_pagespec_function]], there is a "misbehavior" of a `tagged()` pagespec: it matches even pages which have plain links to the tag page.
5 And in general, it would be quite useful to be able to distinguish different kinds of links: one more kind, in addition to "tag", is "bug dependency" noted in [[todo/structured_page_data#another_kind_of_links]] and [[todo/tracking_bugs_with_dependencies#another_kind_of_links]].
7 It could distinguish the links by the `rel=` attribute. ([[Tags already receive a special rel-class|todo/rel_attribute_for_links]].) This means there is a general need for a syntax to specify user-defined rel-classes on wikilink (then bug deps would simply use their special rel-class, either directly, or through a special directive like `\[[!depends ]]`), and to refer to them in pagespecs (in forward and backward direction).
9 Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z.
11 > FWIW, the `add_link` function introduced in a recent
12 > release adds an abstraction that could be used to get
13 > part of the way there to storing data about different types of
14 > links. That function could easily be extended to take an optional
15 > third parameter specifying the link type.
16
17 > Then there's the question of how to store and access the data. `%links`
18 > does not offer a good way to add additional information about links.
19 > Now, we could toss `%links` entirely and switch to an accessor function,
20 > but let's think about not doing that..
21
22 > The data that seems to be needed is basically a deep hash, so
23 > one could check `$linktype{$page}{tag}{$link}` to see if
24 > the page contains a link of the given type. (Note that pages could
25 > contain links that were duplicates except for their types.)
26
27 > There would be some data duplication, unfortuantly, but if `%linktype`
28 > is not populated for regular wikilinks, it would at least be limited to
29 > tags and other unusual link types, so not too bad.
30
31 > `%linktype` could be stored in `%pagestate`.. if so
32 > the actual use might look like `$pagestate{$page}{linktype}{tag}{$link}`.
33 > That could be implemented by the tag plugin right now
34 > with no core changes. (BTW, then I originally wrote tag, pagestate
35 > was not available, which is why I didn't make it differentiate from
36 > normal links.) Might be better to go ahead and add the variable to
37 > core though. --[[Joey]] 
39 I saw somewhere else here some suggestions for the wiki-syntax for specifying the relation name of a link. One more suggestion---[the syntax used in Semantic MediaWiki](http://en.wikipedia.org/wiki/Semantic_MediaWiki#Basic_usage), like this:
41 <pre>
42 ... the capital city is \[[Has capital::Berlin]] ...
43 </pre>
45 So a part of the effect of [[`\[[!taglink TAG\]\]`|plugins/tag]] could be represented as something like `\[[tag::TAG]]` or (more understandable relation name in what concerns the direction) `\[[tagged::TAG]]`.
47 I don't have any opinion on this syntax (whether it's good or not)...--Ivan Z.