1 Jul
2008
1 Jul
'08
9 p.m.
On 1 juil. 08, at 11:12, Vincent Massol wrote:
Just thought about a potential use case for storing
the offset: error
reporting.
We'll also need it if we want to do auto completion in the wiki editor
which I think would be nice to have.
Ok I'll try to add offset/length to the rendering module. It's going
to cost us some performance actually since when there are block
transformations you need to recompute the blocks offsets... I still
need to know how it's best to store them for your needs Malaka.
Storing them in the Blocks themselves might cost too much to retrieve
them. I could also store them in some other structure with references
to the blocks. Let me know what you need.
To speed up things I've done a bit of investigations (Malaka, please
integrate with your own findings).
I've looked at how these things are done in other complex projects,
and maybe I think it will not be possible to use the actual rendering
engine's parser as the basis for the Eclipse infrastructure.
The Eclipse JDT uses a FastJavaPartitionScanner
(http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.ui/ui/org/eclipse/…
) that basically implements an ad-hoc scanner for isolating blocks
(there is plenty of while(true), etc., i.e. clearly it isn't a
standard Java parser)
The Groovy editor uses the standard plain RuleBasedPartitionScanner
(http://svn.codehaus.org/groovy/trunk/groovy/ide/groovy-eclipse/org.codehaus…
) suitably customized for its own needs, with a lot of ad-hoc rule-
based scanners (e.g.,
http://svn.codehaus.org/groovy/trunk/groovy/ide/groovy-eclipse/org.codehaus…)
.
Apparently the parsing of the file with the real parser is done only
in the generation of the content outline (and in the error reporting).
This is noticeable in the Java IDE: the content outline is updated
only when the file is saved (i.e., compiled and so parsed with the
actual Java parser). The same is also true in the Groovy code and in
the XMLEditor example where the SAXParser is called in the
OutlineContentProvider when the document is saved.
Why this architecture is necessary, imho, is because the editor's
parser should be as loose as possible and resilient to (transient)
errors. In fact, when the user is typing the document is almost always
in an inconsistent state (which makes the real parser fail). Examining
the document while editing with the actual parser also means to parse
the document at every keystroke: that's what happens in practice: the
partitioner is asked to return next tokens starting from arbitrary
positions of the text: a request that is not very well fulfilled by
the real parser.
From these considerations, I think that probably using the rendering
engine's parser is not feasible, and we will need to backtrack and
build a "parallel" infrastructure for parsing XWiki documents.
Infrastructure that has already been put in place by Venkatesh and
that Malaka, at this point, will finish and improve for supporting all
the necessary features and variants.
Malaka could you comment on this?
And in general, WDYT?
-Fabio