>I’ve been working on the Visual Editor for XML for the last couple of weeks. Mainly getting it to the point where it is more closely integrated with the support that WTP XML editor and DTD editor provide. One of the features that is needed, is a MultiPage editor version of the VEX editor. A Visual design page as it currently has, and the need for a Source Editor. The source editor should leverage the existing WTP XML source editing abilities and inherit all of it’s features. The issue is that the VEX Visual Editor content model keeps track of offsets completely differently than the standard SSE and WTP DOM implementations. This is understandable because they are truly keeping track of two different types of models.
So, the big challenge has been how to get the existing VEX model into a form that can be more easily made to talk to WTP’s DOM implementation, when being used as a MultiPage editor. WTP has a very sparsely documented set of classes known as EMF2SSEDOM. These classes allow the synchronization of an EMF based model, and the WTP SSE DOM model. So began the migration of the VEX JDOM like model, to an EMF representation.
Lots of little changes had to be done. With lots of little refactorings, but as shown above the first cut is looking good. The model itself is reversed engineered using EMF’s java annotations, and I’ve made some heavy use of generics in Java 5. With 1.4 on its end of life transition period, it was a good time to take advantage of what generics offer. The image itself was generated using the Ecore Tools ecore diagrammer. There are several things that this representation shows off the bat:
- Processing Instructions aren’t modeled or handled.
- Comments aren’t modeled or handled.
- Attributes aren’t modeled as well as they should be.
- Elements and Attributes are not namespace aware.
- It only handles DTDs no XML Schema, or possibility for Relax NG information to be included. (This later issue of only handling DTD has been addressed partly by migrating to the WTP content model for grammars, which handles both DTD and XML Schemas).
In fact currently, VEX basically ignores these when it is reading and creating it’s model via SAX2 processing. These issues will need to be addressed in future iterations of the model before I’m comfortable enough with doing the generation of the code, and then filling in the necessary implementation code.
Why model this using EMF and ecore? Mainly because I needed to get the WTP and VEX models talking together in a relatively short period of time, and a generated EMF model has a lot of the notification and adapter code already written when you generate the model. Secondly, I needed something to get my feet wet with EMF. I am a believer in the potential for modeling, and generated code, but only if it’s used and implemented correctly. Just because you can generate code, doesn’t necessarily mean you should. In this particular instance, I think the benefits will out weigh any disadvantages that may occur with using EMF.
An important point for those considering migrating an existing model. Make sure you have Unit Tests to help verify that you aren’t messing anything up during your refactorings. It would have been near impossible to get the existing model cleaned up and to the point it is now, without having the unit tests. Running these during refactorings help make sure I didn’t bust anything major. The only times I ran into trouble and had to go back to prior code, was when I tried to do too much between running the tests. Run your tests often, make sure they are well written as well, so you know exactly why something is failing. Your tests should not be dependent upon each other, if they are refactor them (I had to break up some tests because of they were interdependent). Having clearly written tests, is just as important as having clearly written code that you are testing.
Anyways, I hope to finish this migration within the next couple of weeks, so that a Multipage Editor version of the VEX editor can be made available.