This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
blog:emf_as_vep_s_model_description_language_2 [2008/04/26 21:57] djo created |
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. | ||
+ | |||
+ | ~~LINKBACK~~ | ||
+ | ~~DISCUSSION:closed~~ | ||