User Tools

Site Tools


Sidebar

Dave Orme muses about data-first development.

My current work emphasizes data engineering and analysis using Kubernetes, Clojure, Scala, Eclipse, and Google Cloud Platform or AWS.


Blog

The Cloud

Scala, Clojure, and FP

Data-First Development

Agile

Older work

Coconut Palm Software home


Donate Bitcoin:

1Ecnr9vtkC8b9FvmQjQaJ9ZsHB127UzVD6

Keywords:

Kubernetes, Docker, Streaming Data, Spark, Scala, Clojure, OSGi, Karaf, GCP, AWS, SQL

Disclaimer:

Everything I say here is my own opinion and not necessarily that of my employer.

blog:emf_as_vep_s_model_description_language_2

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~~

blog/emf_as_vep_s_model_description_language_2.txt · Last modified: 2014/10/17 22:08 (external edit)