diff options
Diffstat (limited to 'doc/todo')
| -rw-r--r-- | doc/todo/inlines_inheriting_links.mdwn | 19 | ||||
| -rw-r--r-- | doc/todo/matching_different_kinds_of_links.mdwn | 28 |
2 files changed, 47 insertions, 0 deletions
diff --git a/doc/todo/inlines_inheriting_links.mdwn b/doc/todo/inlines_inheriting_links.mdwn index 12531990c..c53da51c5 100644 --- a/doc/todo/inlines_inheriting_links.mdwn +++ b/doc/todo/inlines_inheriting_links.mdwn @@ -18,3 +18,22 @@ This is not just an ugly workaround. The availability of this feature has some r So in a sense, in some or most cases, it would indeed be cleaner to "store" the definition of a class of pages referred to in complex pagespecs as a separate object. And the most natural representation for this definition of a class of pages (adhering to the principle of wiki that what you mean is entered/stored in its most natural representation, not through some hidden disconnected code) is making a page with an inline/map/or the like, so that at the same time you store the definition and you see what it is (the set of pages is displayed to you). I would actually use it in my current "project" in ikiwiki: I actually edit a set of materials as a set of subpages `new_stuff/*`, and I also want to have a combined view of all of them (made through inline), and at another page, I want to list what has been linked to in `new_stuff/*` and what hasn't been linked to.--Ivan Z. + +> I see where you're coming from, but let's think about +> immplementation efficiency for a second. +> +> In order for inline inheritlinks=yes to work, +> the inline directive would need to be processed +> during the scan pass. +> +> When the directive was processed there, it would need +> to determine which pages get inlined (itself a moderatly +> expensive operation), and then determine which pages +> each of them link to. Since the scan pass is unordered, +> those pages may not have themselves been scanned yet. +> So to tell what they link to, inline would have to load +> each of them, and scan them. +> +> So there's the potential for this to slow +> down a wiki build by about a factor of 2. +> --[[Joey]] diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn index d3c3a1375..b71d7cc5f 100644 --- a/doc/todo/matching_different_kinds_of_links.mdwn +++ b/doc/todo/matching_different_kinds_of_links.mdwn @@ -7,3 +7,31 @@ And in general, it would be quite useful to be able to distinguish different kin 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). Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z. + +> FWIW, the `add_link` function introduced in a recent +> release adds an abstraction that could be used to get +> part of the way there to storing data about different types of +> links. That function could easily be extended to take an optional +> third parameter specifying the link type. +> +> Then there's the question of how to store and access the data. `%links` +> does not offer a good way to add additional information about links. +> Now, we could toss `%links` entirely and switch to an accessor function, +> but let's think about not doing that.. +> +> The data that seems to be needed is basically a deep hash, so +> one could check `$linktype{$page}{tag}{$link}` to see if +> the page contains a link of the given type. (Note that pages could +> contain links that were duplicates except for their types.) +> +> There would be some data duplication, unfortuantly, but if `%linktype` +> is not populated for regular wikilinks, it would at least be limited to +> tags and other unusual link types, so not too bad. +> +> `%linktype` could be stored in `%pagestate`.. if so +> the actual use might look like `$pagestate{$page}{linktype}{tag}{$link}`. +> That could be implemented by the tag plugin right now +> with no core changes. (BTW, then I originally wrote tag, pagestate +> was not available, which is why I didn't make it differentiate from +> normal links.) Might be better to go ahead and add the variable to +> core though. --[[Joey]] |