Hi Gary ! :) I'm posting inline replies based on what I considered in the patches I'm developing my side for #390
On 2/27/13, Gary Martin <[email protected]> wrote: > On 26/02/13 09:07, Andrej Golcov wrote: [...] >> >> And wiki links will probably look like (as far as I understand >> previous discussion on this subject): >> #<delimiter>1 - I think we cannot use "#1" since it should be reserved >> for relative within product links to avoid migration problems >> #prod1<delimiter>2 >> #prod2<delimiter>3 >> >> IMHO, it is user confusing. >> > > I don't think that #prod1<delimiter>123 works for me. +1 > Would we also > expect to see milestone:prod1<delimiter>milestone1 as appropriate? definitely no [..] > I am expecting #123 to resolve to the appropriate ticket number within > each product which, as already pointed out, helps with migration > problems. +1 > I don't see why this would be a particular problem for the > global env. #123 works equally well there when you are within global scope. > yes > For me, the only issue is how tickets within a product will refer to > tickets in the global scope. There are actually a fair number of > potential solutions including: > > 1. Reserve a keyword to represent the global env (e.g. def, default, > global, null or whatever) This is it ! I'm considering global: prefix and it will work in a similar way to Intertrac prefixes e.g. global:ticket:333 , global:#333 , ... > 2. Allow for a missing product within product syntax to work (e.g. > <delimiter>123, -1 > <delimiter>#123, -1 > product:#123 IMO global: is less ambiguous . Besides this form will over-complicate for no reason the solution . At present this will generate an URL of the form /products/%23123 which would be equivalent to a link to product having prefix '#123' . Whether we shall allow using such prefixes or not is another discussion ; and if not they will always be rendered as 'missing product' links thus hinting that something went wrong in first place . > and product::ticket:123) This one *might* work as it's less ambiguous and should be matched by the TracLinks resolver . If you see some value in using these , please let me know so that I can add it sooner than later . > 3. Use empty quotes to miss out the product prefix (e.g. > ''<delimiter>123, -1 > ''<delimiter>#123, > product:'':#123 and > product:'':ticket:123) > AFAICS these might not work even if it seems they should. I say so based on similar test cases I just wrote , and it seems to me that the TracLinks resolver will leave everything after ' chars outside of link definition (since it is in the middle ;) . Anyway I'll add a test case to confirm this , because the ones mention employ " chars , so they might be treated slightly different. > We could also consider only allowing the longhand forms of 2 or 3 above. > I find myself leaning towards a reserved product name +1 Summarizing , we both are in sync Gary . Further comments are welcome , of course . I'll consider all these forms to write test cases and see where them all will take us . /me working on this ... should be ready soon . -- Regards, Olemis.
