The RevisionLinkPlugin allows you to link to a previous version of a topic. Spinning this idea further we could support a set of attributes for links. This can be done using the "OO dot" notation. A link would be Web.TopicName.attribute, with optional "Web." and ".attribute". Examples:

You type	You get
TopicName	Link to latest version of topic (current spec)
Web.TopicName	Link to topic in other web (current spec)
TopicName.r5	Link to revision 5 of topic
Web.TopicName.r5	Link to revision 5 of topic in other web
TopicName.r-1	Link to previous revision of topic
TopicName.diffs	Link to diffs (all revision diffs of topic)
TopicName.refby	Link to find topics pointing to this topic
TopicName.edit	Link to edit topic
TopicName.attach	Link to attach screen
TopicName.file.cool.gif	Link to attached file cool.gif
TopicName.parent	Link to parent of topic
TopicName.rev	Revision number of latest topic revision
TopicName.username	Login name (jsmith) of latest topic revision
TopicName.wikiname	Wiki name (JohnSmith) of latest topic revision
TopicName.wikiusername	Wiki user name (Main.JohnSmith) of latest topic revision
TopicName.date	Date of latest topic revision
TopicName.export.pdf	Export the topic to pdf (or other pre-rendered type)
TopicName.print	Displays in print skin and brings up browser's "file-print" menu
TopicName.trash	Links to the "Move to Trash" topic for TopicName
TopicName.refactor	Sends TopicName to become a child of Refactor web, or Web.Refactor once OO exists; Refactor is where the owner of the web must refactor the topic or delete it (i.e. force a refactor!)
what else ?
TopicName.raw	Link to raw view of topic
TopicName.isForm	Flag indicating whether a topic is a form or not
TopicName.parent	Topic's parent
TopicName.r5.?recursive?	Should all the above attributes apply recursively to revisions?
TopicName.r5.date	Date of topic revision 5
TopicName.r5.username	Login name (jsmith) of revision5
TopicName.r5.raw	Login name (jsmith) of revision5
TopicName.parent.date	Date of last revision of parent

This is a spec change, potential side-effects need to be looked at. The chance of false hit is very low. For example, there is no problem if the topic name is the last word in a sentence since there is usually a space (or two) before the next sentence. As in: "Links are done automagically with WikiWords. diff allows you to see the history of a topic."

-- PeterThoeny - 09 Sep 2003

Very interesting...

-- PeterMasiar - 09 Sep 2003

I've added a few potentials up top. The changes I made include:

• I changed TopicName.username.r5 to TopicName.r5.username which made more sense to me
• Then I added "raw" and "parent"
• Then I suggested that all of the "non-revision" attributes should apply to revisions as well. For example, if TopicName.username exists, then TopicName.r5.username maybe should exist as well.

It might also be nice to be able to pass CGI parameters this way (or in a similar way) right now if a link is made to something like TopicName?cgi_param=value then it breaks the Wiki link. Perhaps having something like TopicName.set.cgi_param.value or something like that. It might also be interesting to retrieve META data directly from a page. Perhaps even a way to read form defaults and hidden CGI parameters off of a page. A type of TopicName.read.form.cgi_param or something. There are numerous problems with this, which I'll hint on below. However, I'm just trying to toss out all of these ideas to try to brainstorm other implications of this addition; I'm not suggesting any of these ideas are worth actually implementing.

One question though -- how exactly would these be rendered? They wouldn't be rendered as links. Would they just replace the WikiWord entirely with the result of the query? That is a major change indeed. It may open some sort of pandora's box of emergent possibilities. For example, someone might want a "typeof" attribute that could go in front of any attribute to see what type it is. This requires some sort of vectored information to keep track of attribute types as well as values. (imagine TopicName.typeof.date returning "date string" or something)

I realize this is a bit of a stretch to suggest this, but as TWiki leans more toward object attributes and object-orientation, I can see how someone might want TWiki text to be able to either integrate with (or somehow replace) JavaScript. Maybe this is a good thing, maybe not. It would be neat to be able to write JavaScript within a TWiki page using TWiki words and attributes. But is this too big of a change?

-- TedPavlic - 09 Sep 2003

Are they attributes or are they methods.

The short notation .r5 throws away the major revision number. Hopefully someday TWiki will allow checkpointing a topic to the next major revision. So the notation becomes .rN.M or some other variation. Just using .rN might be shorthand for v1.N, but it could also be ambiguous.

Also, the revision should likely be last, in order to apply any of the methods to the revision number, i.e. TopicName.print.r5.

Some of these may be useful for administration tasks, i.e. instead of having to browse and view TopicName.export.pdf, you could use an automated tool, like this: webget http://localhost/twiki/view/TopicName.export.pdf.

-- JonathanCline - 11 Sep 2003