| 39 | | are somehow related, like for traditional backlinks |
| 40 | | (however, for a backlink, Trac will also show the text that surrounds |
| 41 | | the link in the source Wiki text, so that the implicit semantic |
| 42 | | can be easily guessed). |
| | 45 | are somehow related, like with traditional backlinks. |
| | 46 | |
| | 47 | However, in the cross-references listing, for each backlink, |
| | 48 | Trac will also show an excerpt of the source Wiki text |
| | 49 | containing the link, so that the implicit semantic can be |
| | 50 | easily guessed. |
| 52 | | Example: |
| | 57 | The `tag` feature (see the |
| | 58 | [http://dev.muness.textdriven.com/trac.cgi/wiki/tags TagIt macro]), |
| | 59 | which could be reimplemented on top of relations, is another. |
| | 60 | |
| | 61 | === Creating Explicit Relations with the UI === |
| | 62 | |
| | 63 | This should be the normal way to create explicit relations. |
| | 64 | For example, the ticket form could be extended to include |
| | 65 | a '''duplicate of''' field, activated when the resolution |
| | 66 | type is set to ''duplicate''. |
| | 67 | The content of that field would be a facet for the ticket |
| | 68 | and any reference found in the facet will create a specific |
| | 69 | ''duplicate-of'' relation, with the ticket as a source and |
| | 70 | the reference as a target. |
| | 71 | |
| | 72 | === Wiki Syntax for Explicit Relations === |
| | 73 | |
| | 74 | If one wants maximum flexibility, it can be convenient to |
| | 75 | use a specific wiki syntax for creating an explicit relation |
| | 76 | from the current object to any other Trac object. |
| | 77 | |
| | 78 | I would propose using `<<...>>`, which can be nicely rendered |
| | 79 | in HTML by [[html(«...»)]]. |
| | 80 | |
| | 81 | Example, with the `tag` relation: |
| | 82 | Writing |
| 56 | | would tag that page with the `xref` tag. |
| | 86 | would relate the Trac object to which this wiki text belongs |
| | 87 | to the Wiki page named "xref", using the explicit relation `tag` |
| | 88 | (i.e. this would `tag` the current page with the `xref` tag). |
| | 89 | |
| | 90 | Multiple targets should be supported too: |
| | 91 | {{{ |
| | 92 | <<tag xref, idea, #1242>> |
| | 93 | }}} |
| | 94 | Would tag this page with the all those 3 objects |
| | 95 | |
| | 96 | ''Undecided issue:'' [[BR]] |
| | 97 | In the above, I assume that unrecognized words |
| | 98 | should be taken as wiki page names, so that one can write |
| | 99 | `idea` instead of `IdeaTag` or `wiki:idea`. |
| | 100 | However, in a facet (like in the '''duplicate of''' example above), |
| | 101 | it might be convenient to add a description to the reference, |
| | 102 | like `this is quite similar to #123, and just a rewording of #431`. |
| | 103 | In that case, only recognized links should be taken as targets, |
| | 104 | of course. |
| | 105 | |
| | 106 | === Displaying Relations in the Wiki === |
| 86 | | currently contains an implementation for it, and work |
| 87 | | is in progress to adapt it for trunk integration |
| 88 | | (any comments welcomed, of course). |
| | 138 | currently contains an implementation for it. |
| | 139 | It's kept in sync with all my other branches |
| | 140 | (TracDiff and InterTrac) and, as such, |
| | 141 | is also kept in sync with the trunk on a regular basis. |
| | 148 | |
| | 149 | === Refactoring Ideas === |
| | 150 | |
| | 151 | It should be noted that this general mechanism could be used |
| | 152 | to reimplement a few things in Trac so that they become more general: |
| | 153 | * the ticket keywords could be reimplemented by using the `tag` relation |
| | 154 | described above. Unifying keywords and tags would enable to attach |
| | 155 | them to any Trac Object (see #695). |
| | 156 | In addition, one could fill the keyword list by picking in a list of |
| | 157 | already existing keywords. |
| | 158 | * the ticket components could be be reimplemented using a |
| | 159 | ''has-component'' relation, with the components being |
| | 160 | wiki pages (1). The advantage would be that a ticket could have multiple |
| | 161 | components, and that the component could be documented and used in a |
| | 162 | meaningful way in other relationships (e.g. #548, #1678 and |
| | 163 | TracMultipleProjects/SingleEnvironment#UsingComponentobjects) |
| | 164 | * idem for the versions, using a ''has-version'' relation |
| | 165 | |
| | 166 | ---- |
| | 167 | (1):: |
| | 168 | ... Wiki pages created from a !ComponentTemplate page, therefore |
| | 169 | having an ''is-a'' relationship to the above !ComponentTemplate page. |
| | 170 | This makes it simple to retrieve all components: |
| | 171 | those are the `[[Relation(<<is-a ComponentTemplate>>)]]` objects, |
| | 172 | or, in Python code, |
| | 173 | {{{ |
| | 174 | #!python |
| | 175 | components = WikiPage(self.env, 'ComponentTemplate').sources('is-a') |
| | 176 | }}} |
| | 177 | Of course, the !ComponentTemplate ''is-a'' !TemplateTemplate... |
