/* Will be some what Greek to someone who hasn’t worked with Eclipse, so you have been warned */
Yes, some must be wondering on this. But it all comes to the fact that planning a software project is the hardest part of the procedure, and that I was having a hectic period for last 2 weeks because of my academic stuff. But it’s settling to a steady phase now and I’m having some time to start coding again after a while. Also about planning of the project, my mentor and I talked heavily on the best and easiest path to take by using already existing resources such as the existing XPath parser (which is mostly done by David himself) and XSL plugin.
So now what I’m trying to do now is (and somewhat stuck at),
1) Partition the editor into content types.
2) Use existing content types to read patterns such as XML.
3) Create parsers for XPath2 and XQuery content types.
4) Make AST out of these 2 new content types to do more fancy stuff like content assistance
IMHO these 4 steps are the heart of this plug-in since almost all other fancy UI stuff are based on the success of this. In order to implement those so called fancy UI stuff I will be extending the Structured Source Editor(SSE) since it’s the best course of action for a XML editor.
Another factor that has been lagging the speed of this project is the lack of documentation for SSE and how to make partitioning based on content types. Best support materials I found that could be used practically were few slides from EclipseCon and other editor plugins similar to this such as XSL, XPath, JSP and PHP editors, which David helped a lot suggesting and finding them. It was somewhat hard at first to comprehend the structure of SSE but reviewing these existing plugins helped it.
I’ve created the project at SourceForge Eclipse incubator for now and you can check it out from there as the project goes and I will use this post series to bring news of the progress of my new buddy.
More News: http://wiki.eclipse.org/New_Eclipse_Plugin_for_XQuery