bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Apache Bloodhound] #390: Product wiki syntax
Date Mon, 04 Mar 2013 22:39:36 GMT
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 <> 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.


> The forms for the links will therefore be
>   * <reslink>
>   * product:<prefix>:<reslink>
>   * <prefix><sep><reslink>


> 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'


>   * 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



View raw message