In a previous entry, I discussed some of the advantages and disadvantages of using EMF as the model-description language in VEP. Here we'll take a quick look at some of the implications of implementing the model this way.

The reason why EMF and VEP dovetail so nicely is that visual editors need to be able to describe and access meta-information about the user interface objects that they need to manipulate.

Java has two built-in ways to do that: java.beans.* and java.lang.reflect.*. But VEP needs to be language-neutral, so it can't use either of those two “standards” directly. It needs a language-neutral way to describe the same thing.

Enter EMF: EMF provides similar functionality to java.lang.reflect, but in a language-neutral format. It was designed for describing object models and manipulating them in a generic way using Java. But because EMF describes generic object models rather than Java object models, the object model that EMF describes could also be a C/C++ object model. Or a PHP object model. Or an XML document object model…

The result is that EMF as VEP-model-layer solves the language and architecture problem really neatly across several problem domains.

~~LINKBACK~~ ~~DISCUSSION:closed~~