4 Jun
2008
4 Jun
'08
4:22 p.m.
On 4 juin 08, at 14:49, malaka ekanayake wrote:
hi fabio,
It will get another 2 days to get my new internet connection.So what
should I do till I get my connection.Unfortunately I will not be
able to look at the new XE release.:-(
Should I look in to implement syntax assistance for one language
(xwiki syntax) or should I need to think of all the syntax at the
first since xwiki pages will include a mix of several syntaxes .The
article I have found explains how to implement syntax for SQL.I
think by getting help from you I will be able to implement syntax
asistance for one laguage.So what path I should take.
The trick here is to well engineer the partitioner, i.e., the
component that will break the actual text in a set of disjoint areas
(the partitions) with a given content type.
This is basically what is done in http://www.realsolve.co.uk/site/tech/jface-text.php
where several partition types are identified.
Once a good "partitioning model" for the document is built, then each
partition, depending on its content-type, can be associated to a
scanner for syntax highlighting, a content formatter, a content
assistant, etc. All these components, in fact, can be assigned on a
per-partition basis. This means that the granularity of the partitions
should be evaluated even with respect to what support should be given
to the user.
For example, the partitioner could return a huge single partition of
type XWIKI_DOCUMENT. But what a content assistant would be able to
suggest in this case? Not too much. In the XML-Editor example the
partitioner wisely identifies XML_START_TAG partitions so that a
content assistant associated to this partition type can usefully
suggest all the tags defined in the corresponding DTD. In XWiki, for
example, an XWiki link is a good candidate for a partition type.
This doesn't answer the question of how to architect a good
partitioner for a document containing multiple languages... I would
say that it should be possible to modularize partitioners, i.e.,
having a partitioner for XWiki, one for Velocity, one for Groovy, etc.
and then have a main partitioner that delegates the work to the others
when it see a given pattern. A good starting point for understanding
if and how this could be done, is to have a look at the JDT code.
After all a Java editor handles, in the same document, the Java and
JavaDoc languages.
To be practical I would suggest to start simple. You might try to
write a standalone plugin (you can also start from the plugin with an
editor template) with partitioner and a highlighter that is able to
process the plain XWiki document, and to provide syntax highlighting
for basic XWiki syntax elements. This should show you what are the
issues in building such a kind of extension. Then we could try to
think about velocity snippets and to combine what you wrote with
something velocity specific.
Even though you don't have the latest XEclipse, integrating your
standalone plugin into XEclipse would be only a matter of setting your
SourceViewerConfiguration in the constructor of
org.xwiki.eclipse.ui.editors.PageEditor.
Let's set a deadline in a week to see how far you can go.
It would be good to have your plugin committed in the sandbox so that
we can work together. Probably Vincent or another administrator can
give you an account for accessing the sandbox.
Of course, feel free to ask question in the meanwhile :)
Cheers,
Fabio