sections/overview/overview.html - www.eclipse.org/eef - Git at Google

 <md-content layout="column" layout-align="center stretch" class="content">
   <h2>Eclipse EEF</h2>

   <h3>Goal</h3>
   <p>
     The goal of EEF is to improve the edition of EMF models by providing a way to create advanced user interfaces for your models easily.
   </p>

   <h3>History</h3>
   <p>
     The EEF project has been created in <a href="https://eclipse.org/proposals/eef/">2009</a>. EEF has participated in all simultaneous releases of Eclipse since Eclipse 3.6 Helios in 2010 (<a href="https://www.eclipse.org/helios/">Helios</a>, <a href="https://www.eclipse.org/indigo/">Indigo</a>, <a href="https://www.eclipse.org/juno/">Juno</a>, <a href="https://www.eclipse.org/kepler/">Kepler</a>, <a href="https://www.eclipse.org/luna/">Luna</a>, <a href="https://www.eclipse.org/mars/">Mars</a>, <a href="https://www.eclipse.org/neon/">Neon</a>).
   </p>
   <p>
     The first version of EEF (0.7 -> 1.5.x) used a code generation-based approach in order to create a powerful user interface for EMF models. This version has been used successfully in several products like <a href="http://www.umldesigner.org">UML Designer</a> or <a href="https://www.eclipse.org/ecoretools/">Ecore Tools</a>. Following the development of an advanced prototype using a declarative approach without any generated code, a new version of the project was started from scratch in summer 2015. This brand new version (EEF 1.6.0) has been launched in order to achieve new goals including:
   </p>
   <ul>
     <li>Be the perfect solution to build properties view for Eclipse Sirius</li>
     <li>No links to the metamodel, everything can be computed using expressions</li>
     <li>Support for the <a href="https://www.eclipse.org/acceleo/documentation/aql.html">AQL interpreter</a> and all the other interpreters available in Eclipse Sirius (var, feature, service, etc)</li>
     <li>It should be easy to define simple use cases and complex use cases should be supported</li>
     <li>Almost no dependencies, EEF must be as light as possible</li>
     <li>Provide a wide range of widgets for most use cases</li>
   </ul>
   <p>
     With this new version of Eclipse EEF, our goal was to be the solution to build properties view for Sirius-based designers. As a result, the domain specific language used by EEF to describe the properties view needed to evolve to support the same advanced use cases as Eclipse Sirius and to embrace the same philosophy. The complex use cases that EEF will have to support includes meta-models with hundreds of EClasses and thousands of EStructuralFeatures.
   </p>
   <p>
     To handle those kinds of meta-models, we could not have a dependency with the meta-model anymore, just like Eclipse Sirius, the new version of EEF needed to be able to use expressions to compute everything. With the concept of domain class and semantic candidate expressions, you can create a view for various objects that do not have to share a common superclass and using our dynamic mappings you can even create advanced rules like the creation of a text field for all the properties of your object with the type EString.
   </p>

   <h3>Relations to other projects</h3>
   <p>
     EEF is a part of the <a href="https://eclipse.org/modeling/">Modeling</a> community of the Eclipse Foundation and it uses heavily the <a href="https://eclipse.org/modeling/emf/">Eclipse Modeling Framework</a> (EMF). While the first version of EEF (0.7 -> 1.5.x) has been used to create user interfaces of several Sirius-based designers, both projects had different approachs to fullfil their objectives. The new version of EEF (1.6.0) is now sharing completely the philosophy used by <a href="https://eclipse.org/sirius/">Eclipse Sirius</a> which makes EEF more powerful to handle complex problems. With this new approach, uses familiar with Eclipse Sirius will be able to get started with Eclipse EEF very easily. It has also an impact on the project itself because the compatibility with Eclipse Sirius is a critical goal for the project. EEF will thus support all the platforms supported by Eclipse Sirius and both projects are even sharing some common code.
   </p>
   <p>
     The first version of EEF, based on a code generation approach relied on <a href="https://eclipse.org/acceleo/">Acceleo</a> for the generation of the code. In the new version of EEF, the project is not generating code anymore since it has embraced an interpreted approach. Yet this change has not removed all links from EEF to Acceleo since Acceleo is now providing a light and powerful navigation and query language named AQL (Acceleo Query Language) which will be one of our most used interpreter for the expressions written in an EEF-based properties view.
   </p>

   <h3>Architecture</h3>
   <p>
     The first version of the project used the namespace org.eclipse.emf.eef but since we want to be able to deliver to our users both the old and the new version of the project, its has been decided that the new version would switch to the namespace org.eclipse.eef. The components of EEF can be separated in six categories:
   </p>
   <ul>
     <li>The domain specific language with org.eclipse.eef and org.eclipse.eef.edit</li>
     <li>The core with org.eclipse.eef.common, org.eclipse.eef.core and org.eclipse.sirius.common.interpreter from Eclipse Sirius</li>
     <li>The IDE part with the bundle org.eclipse.eef.ide</li>
     <li>The user interface with org.eclipse.eef.common.ui and org.eclipse.eef.ide.ui</li>
     <li>The integration in the properties view with org.eclipse.eef.ide.ui.properties</li>
     <li>The Eclipse Properties support with org.eclipse.eef.ui.properties</li>
   </ul>
   <p>
     Only the two last parts are dependent of the Eclipse properties view framework. As a result, you can use EEF programmatically to build other user interface elements like wizards.
   </p>
 </md-content>
	<md-content layout="column" layout-align="center stretch" class="content">
	<h2>Eclipse EEF</h2>

	<h3>Goal</h3>
	<p>
	The goal of EEF is to improve the edition of EMF models by providing a way to create advanced user interfaces for your models easily.
	</p>

	<h3>History</h3>
	<p>
	The EEF project has been created in <a href="https://eclipse.org/proposals/eef/">2009</a>. EEF has participated in all simultaneous releases of Eclipse since Eclipse 3.6 Helios in 2010 (<a href="https://www.eclipse.org/helios/">Helios</a>, <a href="https://www.eclipse.org/indigo/">Indigo</a>, <a href="https://www.eclipse.org/juno/">Juno</a>, <a href="https://www.eclipse.org/kepler/">Kepler</a>, <a href="https://www.eclipse.org/luna/">Luna</a>, <a href="https://www.eclipse.org/mars/">Mars</a>, <a href="https://www.eclipse.org/neon/">Neon</a>).
	</p>
	<p>
	The first version of EEF (0.7 -> 1.5.x) used a code generation-based approach in order to create a powerful user interface for EMF models. This version has been used successfully in several products like <a href="http://www.umldesigner.org">UML Designer</a> or <a href="https://www.eclipse.org/ecoretools/">Ecore Tools</a>. Following the development of an advanced prototype using a declarative approach without any generated code, a new version of the project was started from scratch in summer 2015. This brand new version (EEF 1.6.0) has been launched in order to achieve new goals including:
	</p>
	<ul>
	<li>Be the perfect solution to build properties view for Eclipse Sirius</li>
	<li>No links to the metamodel, everything can be computed using expressions</li>
	<li>Support for the <a href="https://www.eclipse.org/acceleo/documentation/aql.html">AQL interpreter</a> and all the other interpreters available in Eclipse Sirius (var, feature, service, etc)</li>
	<li>It should be easy to define simple use cases and complex use cases should be supported</li>
	<li>Almost no dependencies, EEF must be as light as possible</li>
	<li>Provide a wide range of widgets for most use cases</li>
	</ul>
	<p>
	With this new version of Eclipse EEF, our goal was to be the solution to build properties view for Sirius-based designers. As a result, the domain specific language used by EEF to describe the properties view needed to evolve to support the same advanced use cases as Eclipse Sirius and to embrace the same philosophy. The complex use cases that EEF will have to support includes meta-models with hundreds of EClasses and thousands of EStructuralFeatures.
	</p>
	<p>
	To handle those kinds of meta-models, we could not have a dependency with the meta-model anymore, just like Eclipse Sirius, the new version of EEF needed to be able to use expressions to compute everything. With the concept of domain class and semantic candidate expressions, you can create a view for various objects that do not have to share a common superclass and using our dynamic mappings you can even create advanced rules like the creation of a text field for all the properties of your object with the type EString.
	</p>

	<h3>Relations to other projects</h3>
	<p>
	EEF is a part of the <a href="https://eclipse.org/modeling/">Modeling</a> community of the Eclipse Foundation and it uses heavily the <a href="https://eclipse.org/modeling/emf/">Eclipse Modeling Framework</a> (EMF). While the first version of EEF (0.7 -> 1.5.x) has been used to create user interfaces of several Sirius-based designers, both projects had different approachs to fullfil their objectives. The new version of EEF (1.6.0) is now sharing completely the philosophy used by <a href="https://eclipse.org/sirius/">Eclipse Sirius</a> which makes EEF more powerful to handle complex problems. With this new approach, uses familiar with Eclipse Sirius will be able to get started with Eclipse EEF very easily. It has also an impact on the project itself because the compatibility with Eclipse Sirius is a critical goal for the project. EEF will thus support all the platforms supported by Eclipse Sirius and both projects are even sharing some common code.
	</p>
	<p>
	The first version of EEF, based on a code generation approach relied on <a href="https://eclipse.org/acceleo/">Acceleo</a> for the generation of the code. In the new version of EEF, the project is not generating code anymore since it has embraced an interpreted approach. Yet this change has not removed all links from EEF to Acceleo since Acceleo is now providing a light and powerful navigation and query language named AQL (Acceleo Query Language) which will be one of our most used interpreter for the expressions written in an EEF-based properties view.
	</p>

	<h3>Architecture</h3>
	<p>
	The first version of the project used the namespace org.eclipse.emf.eef but since we want to be able to deliver to our users both the old and the new version of the project, its has been decided that the new version would switch to the namespace org.eclipse.eef. The components of EEF can be separated in six categories:
	</p>
	<ul>
	<li>The domain specific language with org.eclipse.eef and org.eclipse.eef.edit</li>
	<li>The core with org.eclipse.eef.common, org.eclipse.eef.core and org.eclipse.sirius.common.interpreter from Eclipse Sirius</li>
	<li>The IDE part with the bundle org.eclipse.eef.ide</li>
	<li>The user interface with org.eclipse.eef.common.ui and org.eclipse.eef.ide.ui</li>
	<li>The integration in the properties view with org.eclipse.eef.ide.ui.properties</li>
	<li>The Eclipse Properties support with org.eclipse.eef.ui.properties</li>
	</ul>
	<p>
	Only the two last parts are dependent of the Eclipse properties view framework. As a result, you can use EEF programmatically to build other user interface elements like wizards.
	</p>
	</md-content>