Re: [xwiki-devs] [Discussion] Annotations improvements (wider annotations target) and roadmap update

Hi Edi, On 10/30/2009 06:16 PM, Eduard Moraru wrote: either use offset for position of selection in context, or use contextLeft & contextRight (then the whole context becomes contextLeft + selection + contextRight) and this doesn't affect context size. Why? It should work well in most real-life cases. My take is that a frame of 3-5 hundred characters doesn't repeat in a regular document created in a wiki (of course you can build test cases when it fails). If the whole document is not megabytes (in which case you should be able to find a shorter context), I don't see why that is a problem. Well, the whole point is to get the dynamic part to execute and store annotations as text, so that annotations are defined by what the user sees, as a general idea. This also ensures that an annotation could be displayed even if its position moved from one execution to another (for example, in a scripted document, you'd have a part which would only be displayed to admins. If an annotation falls in that part, then for admins would match, for regular users no, which is ok: since the text doesn't appear there's nothing the user expects to be annotated. If an annotation falls in the part outside the content displayed only for admins, then matching by text (and not position) would allow us to find it and display it even if its position moves because of the text rendered only for admins. If it's half-half then for admins it would be there because the content is, for regular users not because the content isn't). For the particular case of a dynamic part generating copies of context, I'm reiterating the idea that a couple of hundred characters should work in normal cases. If there is a dynamic part which duplicates the whole document, the only problem would be that annotation would be matched and displayed on the first encounter of its context, and not the second (is that a pb for what user sees and perceives? or we could also display it 2 times) Also, this is a particular case ("normal" documents shouldn't do that). Of course there would be annotations which will fail to be matched and represented but, if few enough and in particular enough cases, I think it's a good tradeoff. Note that I don't know yet how this performs in practice, but I think it's a good direction to try as a balance between practical performance and speed of implementation, and it's the only one so far (well, there's also the current implementation but that only covers a subset of what this implementation would cover). The idea is that this algorithm is changeable in its key points, like detecting and matching context. This first take is supposed to perform well *in practice*, even if theoretically there are cases where it fails. If these failures make it unusable or we decide we want atomic precision, then we can improve the key points (like trying to match context better and others). Thanks, Anca