User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
blog:emf_as_vep_s_model_description_language_2 [2008/05/06 13:23]
djo Discussion status changed
blog:emf_as_vep_s_model_description_language_2 [2014/10/17 22:08] (current)
Line 1: Line 1:
 +====== EMF as VEP's Model Description Language (2) ======
 +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.