I have been tempted to write a long reply , but I won't . I'll just reply quicly between the lines . Product wiki syntax is almost ready and working . I'm just writing test cases to cover all forms and deal with some exotic . I propose we focus our efforts on discussing about how to improve what I'll submit in the next few days , once we all be aware of the limitations and technical challenges solved and pending ;)
BTW , After getting my hands dirty I realized that *many* of the previous suggestions mentioned before are not even valid TracLinks expressions . That will shape the form of the final solution though . On 3/4/13, Gary Martin <[email protected]> wrote: > On 21/02/13 10:14, Andrej Golcov wrote: >> Regarding prefixing tickets with "#". >> We still have to support #123 notation for wiki links inside the >> product. IMHO, introducing non-relative wiki links for tickets without >> # (e.g. bh/123) can be user confusing. My +1 to leave # for full >> path tickt links, e.g. #produc<delimeter>productid >> >> Regards, Andrej > > In case it isn't spotted from another related thread, I believe that > when using # in the link, it should always appear after any product > specification. +1 > The forms for the links will therefore be > > * <reslink> > * product:<prefix>:<reslink> > * <prefix><sep><reslink> > +1 > where <reslink> is any currently valid resource link (#<id>, > ticket:<id>, milestone:<id>, wiki:<id> etc). +1 ... though ... ;) > In addition, specifically > for tickets and wiki pages we will allow: > > * <prefix><sep><id> > for tickets +1 . for wiki pages I'm not sure > as long as the wiki page matches the current rules for automatically > being interpreted as wikipage links. On this basis we will be able to > match the the form of jira tickets if we choose <sep> = '-' even if we don't choose sep = '-' it seems it may be matched so far I have discarded these chars as prefixes / collisions with relative wiki page refs in wiki context - has a major ambiguity when it comes to expanding raw-attachment and similar TracLinks namespace : TracLinks meta-char , obviously out . collisions with relative wiki I'm starting to think that we should be using one of ~ > 1. prefix~#123 2. prefix>#123 ... or a combination of the former e.g. 3. prefix->#123 I think I'd rather prefer 1 or 3 . In the first version I'll implement (1) > and maybe we > should just do so. Some of the things to consider for that are: > > * false matches on 'var-N' which would either have to be escaped by > one of the standard means or just written as 'var - N' +1 > * potential ambiguity if '-' is allowed in the prefix itself, in any case only alphanumeric (inlcuding unicode) chars will be supported in short forms . > which > might suggest we should avoid the issue by disallowing products > being set up with '-' in the prefix; existing products with this > will work with 'product:<prefix>:<reslink>' syntax of course. > Other kinds of prefixes will make use of link resolvers only . > Does anyone spot any additional problems or have any objections to this? > let the test suite talk , please be patient ;) -- Regards, Olemis.
