Cleanup of the openid login widget, including replacing of hotlinked images from...

[git.ikiwiki.info.git] / doc / todo / flexible_relationships_between_pages.mdwn

diff --git a/doc/todo/flexible_relationships_between_pages.mdwn b/doc/todo/flexible_relationships_between_pages.mdwn
index ee3dd8d3a46fc4c5469a18ff2a8fbf3e561f56e0..cb1ff2b1d38fe7a1895ab96ee688cc9433a91256 100644 (file)
--- a/doc/todo/flexible_relationships_between_pages.mdwn
+++ b/doc/todo/flexible_relationships_between_pages.mdwn
@@ -3,8 +3,11 @@ was tackled, but hardly a plugin is using it.
 
 in order to enhance on the [[todo/rel attribute for links]] and [[todo/better bug tracking support]]
 issues and to provide a more general infrastructure, i'd like to propose a
 
 in order to enhance on the [[todo/rel attribute for links]] and [[todo/better bug tracking support]]
 issues and to provide a more general infrastructure, i'd like to propose a

-generic plugin for typed links. following the use case i've developed it for,
-i'll call it `blocks` for the moment (but am open to better suggestions).
+generic plugin for typed links. it can be also viewed of a way to have
+[[todo/structured page data]] that consists of URLs inside the wiki.
+
+following the use case i've developed it for, i'll call it `blocks` for the
+moment (but am open to better suggestions).

 
 outline
 =======
 
 outline
 =======


@@ -33,6 +36,19 @@ details
   direction (eg `index`, even though one could declare it as
   `index/isindexof`).
 
   direction (eg `index`, even though one could declare it as
   `index/isindexof`).
 

+  > isindexof is not a very interesting relationship - it just clogs up
+  > the link-map, since the index is "the index of" all pages. I can't
+  > see any situation in which you'd want to do pagespec matching
+  > on it? --[[smcv]]
+
+  >> that's why i used `index` as an example of a one-direction relationship.
+  >>
+  >> it wouldn't clog up the link map, though: in order to cleanly match both
+  >> directions, when the "inverse" term of a relationship is used, the link in
+  >> taggedlinks uses the "forward" term, but switches the objects.
+  >>
+  >> --[[chrysn]]
+

   other verbs are symmetric, eg. `equivalent`, which need different treatment.
 
 * "taglink" style directives
   other verbs are symmetric, eg. `equivalent`, which need different treatment.
 
 * "taglink" style directives


@@ -41,6 +57,43 @@ details
   from the autotag and tagdir features). as there is a `\[[!taglink ...]]`
   directive, there could be an analogous directive for every single directive.
 
   from the autotag and tagdir features). as there is a `\[[!taglink ...]]`
   directive, there could be an analogous directive for every single directive.
 

+  > This is basically the traillink/trailitem duality, too.
+  > I'd be quite tempted to generalize to something like this:
+  >
+  >     We can't fix [[!link blocks="bug123" text="Bug 123"]] until we do this.
+  >
+  >     [[!hiddenlink owner="smcv"]]
+  >
+  > but perhaps that's too wordy?
+  >
+  > I think both trail and tag need their own special processing beyond the
+  > general case, but maybe not? --[[smcv]]
+
+  >> i'd be all in favor of having this unified and deeper; there has been the
+  >> idea of a `\[[!link]]` directive [[again|todo/link plugin perhaps too general__63__]]
+  >> and [[again|todo/do not make links backwards]].
+  >>
+  >> i like the `\[[!link text=""]]` and `[[!hiddenlink]]` conventions, but
+  >> think that ${REL}="${TARGET}" isn't ideal because it implies that a single
+  >> link can have more than one target. instead, i'd go for
+  >> `\[[!link to="bug123" rel="blocks" text="Bug 123"]]; as with the html rel
+  >> parameter, rel would be a list of whitespace separated values.
+  >>
+  >> positional parameters (`\[[!link bug123 rel="blocks" text="Bug 123"]]` or
+  >> even `\[[!link Bug 123|bug123 rel="blocks"]]`) would be possible, but i
+  >> prefer explicit syntax and not joining stings back again with the
+  >> whitespace that was split off it before.
+  >>
+  >> if the '|' character is not widespread in page names (which i assume it is
+  >> not), instead of using positional parameters in `\[[!link]]` for
+  >> shortcuts, we could extend the regular link syntax; the same relationship
+  >> could then be declared as `\[[Bug 123|bug123|blocks]]`; this would be an
+  >> easy extension to the original link syntax. it would even work for hidden links
+  >> (`\[[|smcv|owner]]`), which previously made no sense because a link with
+  >> neither a physicial representation nor metadat is of no use.
+  >>
+  >> --[[chrysn]]
+

 * implementation notes
 
   the way pagespec hooks are implemented required some nasty perl tricks, for
 * implementation notes
 
   the way pagespec hooks are implemented required some nasty perl tricks, for


@@ -49,6 +102,13 @@ details
   ideal. a change in the pagespec declaration api (why not just `hook` like
   everything else) would make the implementation cleaner.
 
   ideal. a change in the pagespec declaration api (why not just `hook` like
   everything else) would make the implementation cleaner.
 

+  > How about replacing `blockedby(bug*)` with `linktype(blockedby bug*)` or
+  > something? Then you'd only need one pseudo-hook. --[[smcv]]
+
+  >> there has been the topic of pagespecs like `typedlink(type glob)` back in
+  >> the [[matching different kinds of links]] discussion, but it was removed
+  >> in favor of per-type matchers. --[[chrysn]]
+

 * configuration location
 
   i aimed for static configuration of the `block_names` in the setup file. this
 * configuration location
 
   i aimed for static configuration of the `block_names` in the setup file. this


@@ -75,10 +135,13 @@ details
   consider what is in @links to be a representation of which hyperlinks are
   there, and in this case, none are generated).
 
   consider what is in @links to be a representation of which hyperlinks are
   there, and in this case, none are generated).
 

+  > taglink and traillink already count as wikilinks without generating
+  > any visible HTML. --[[smcv]]
+

 implementation
 ==============
 
 there is a working but slightly incomplete (basically where it comes to the
 details mentioned above) implementation in [[blocks.pm]].
 
 implementation
 ==============
 
 there is a working but slightly incomplete (basically where it comes to the
 details mentioned above) implementation in [[blocks.pm]].
 

---chrysn
+--[[chrysn]]