Developing User Interfaces with EMF Parsley Lorenzo Bettini∗ Dipartimento di Informatica, Universita` di Torino, Torino, Italy Keywords: EMF, Modeling, Eclipse, User Interface, DSL. Abstract: In this paper we describe the main features of EMF Parsley, a new Eclipse project for implementing appli- cations based on the Eclipse Modeling Framework (EMF). EMF Parsley aims at complementing the EMF reflective mechanisms with respect to rapidly creating user interfaces based on models, without having to deal with internal details and setup code. In particular, EMF Parsley uses injection mechanisms to easily customize all the aspects of such applications. Moreover, it provides a set of reusable user interface components like trees, tables and detail forms that manage the model with the introspective EMF capabilities, together with reusable views, editors and dialogs. Besides project wizards, to easily create projects based on EMF Pars- ley, the main developing tool is a DSL, implemented with Xtext/Xbase, that provides a rapid customization mechanism. 1 INTRODUCTION Xtext (Itemis, 2014; Eysholdt and Behrens, 2010; Bettini, 2013a), for making the use of our framework The Eclipse Modeling Framework (EMF) (Steinberg easier: customizations can be specified in a compact et al., 2008) simplifies the development of complex form in a single file. software applications with its modeling mechanisms. EMF Parsley is the evolution of EMF Compo- However, the development of user interfaces based on nents (Bettini, 2012; Bettini, 2013b); EMF Compo- EMF still requires an extensive setup and the knowl- nents was a first experiment with building automati- edge of many internal details. For these reasons, in cally applications based on EMF models. EMF Pars- this paper, we present a new Eclipse framework, EMF ley is a huge evolution with this respect: we focused Parsley; this has been recently approved as an official to make the initial setup easier (using project wiz- Eclipse project and it is in its incubation phase. ards); the same holds for customizations of all the EMF Parsley provides a framework to easily de- behaviors, in particular the DSL helps a lot with this velop user interfaces based on EMF models. The respect. framework hides most of the complexity of internal The paper is structured as follows: in Section 2 we details. Creating a JFace viewer and connecting it introduce our motivations, while in Section 3 we de- to an EMF resource, usually requires a few lines of scribe the design choices and the main features of our code. Furthermore, the customization of specific be- framework by examples. Section 4 describes our DSL haviors is also easy thanks to the use of Google Guice, (and some examples) and Section 5 presents some ad- a Dependency Injection framework, and thanks to the ditional features of EMF Parsley. Section 6 concludes polymorphic method dispatch mechanism that allows the paper with related work and hints for future direc- to write cleaner declarative code. This maximizes tions. code reuse and promotes a programming style where the classes implemented by the programmer are usu- ally very small and deal with only a few aspects. The 2 MOTIVATIONS framework comes with some UI widgets to be used out-of-the-box (including trees, tables, dialogs and forms, and view and editor parts). EMF.Edit (Steinberg et al., 2008) is an EMF frame- We also provide a DSL, implemented in work with generic reusable classes for editing EMF models. The programmer can use these mechanisms ∗The paper was partly supported by RCP Vision, to implement UI parts for the EMF models. The prob- www.rcp-vision.com. lem is that all these mechanisms have to be setup and 58 Bettini L.. Developing User Interfaces with EMF Parsley. DOI: 10.5220/0004990800580066 In Proceedings of the 9th International Conference on Software Paradigm Trends (ICSOFT-PT-2014), pages 58-66 ISBN: 978-989-758-037-6 Copyright c 2014 SCITEPRESS (Science and Technology Publications, Lda.) DevelopingUserInterfaceswithEMFParsley 1 adFact = new ComposedAdapterFactory( public class BookItemProvider extends ... ComposedAdapterFactory.Descriptor.Registry. 2 f INSTANCE); /∗∗ @generated NOT ∗/ adFact.addAdapterFactory(new 4 @Override public Object getImage(Object object) ResourceItemProviderAdapterFactory()); f 3 adFact.addAdapterFactory(new return overlayImage(object, MyModelItemProviderAdapterFactory()); 6 getResourceLocator().getImage("mypath/ adFact.addAdapterFactory(new custom_book.png")); g ReflectiveItemProviderAdapterFactory()); 5 8 /∗∗ @generated NOT ∗/ BasicCommandStack cmdStack = new @Override public String getText(Object object) f BasicCommandStack(); 10 return "Book: " + "" + ((Book)object). 7 cmdStack.addCommandStackListener(new getTitle(); CommandStackListener()f...g); g 9 edDom = new AdapterFactoryEditingDomain( Listing 2: An example of typical customization of EMF adFact,cmdStack,...); labeling. 11 Tree tree = new Tree(composite, SWT.MULTI); ResourceLocator, etc.). Furthermore, if we want TreeViewer viewer = new TreeViewer(tree); to customize the labels and images for all the ele- 13 ments of the model, we need to modify all generated viewer.setContentProvider(new ItemProvider classes. With this respect, we want to AdapterFactoryContentProvider(adFact)); provide in EMF Parsley a much easier customization 15 viewer.setLabelProvider(new AdapterFactoryLabelProvider(adFact)); mechanism. viewer.setInput(edDom.getResourceSet()); A problem with the @generated and @generated 17 NOT mechanism is that it is difficult to keep track of new AdapterFactoryTreeEditor(viewer.getTree(), custom modifications to the generated code. Indeed adFact); generated and custom code are mixed together in the Listing 1: An example of typical use of EMF.Edit. same Java file. This makes such code much harder to maintain. A more appealing solution is the Gen- eration Gap (Vlissides, 1996), a pattern that solves initialized correctly in order to achieve the desired the problem of maintainability of coexisting gener- features. This initialization phase takes many lines ated and manual code by relying on class inheritance: of code, and usually requires some deeper knowledge there will be a class that encapsulates generated code of EMF internals. In Listing 1 we show the typical and another one class that encapsulates modifications. Java code one needs to write to setup a viewer with We will follow this pattern in the DSL (as we will EMF.Edit. As we will show in the next sections, our show in Section 4). By using this pattern, generated goal is to factor out this boilerplate code in such a way and custom code are clearly separated in different files that UI components can be setup with only a few lines and are then much easier to maintain (in our case, they of code. are also stored in different source folders). Keeping EMF has some generation mechanisms for the generated and custom code separate also makes it eas- user interface. However, there are many problems ier to store them in source control systems (e.g., Git, when using this generated code; we will detail such SVN, etc.); not to mention that when using a contin- problems in the following. uous integration build system, generated code needs EMF generation mechanisms are based on not to be checked in the version control system, since Javadoc comments @generated for fields, methods it can be generated during the build. This significantly and classes. Future generations will overwrite all the reduces the size of the source control system database. previously generated Java code elements unless the For all these reasons we felt the need of creating a programmer removes that @generated from specific new framework built on top of EMF, to avoid all the declarations (or replaces it with @generated NOT). above issues and to make the creation, customization In Listing 2 we show an example of customiza- and maintenance of EMF applications much easier, as tion of labeling in a class generated by EMF (related we will show in the next sections. to the classic EMF Library example). In order to specify the image for instances of Book we need to go into the generated ItemProvider class, and spec- ify the path of the image (note the presence of other distracting and internal details like overlayImage, 59 ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends 3 EMF PARSLEY 1 class MyModule extends EmfParsleyGuiceModule f In this Section we present the most relevant fea- public Class<? extends ResourceLoader> bindResourceLoader() f tures of EMF Parsley through examples; this Eclipse 3 return MyResourceLoader.class; project is still in the incubation phase, thus more fea- g tures will be provided in the future (see also Section 6 5 public Class<? extends ILabelProvider> for future work). bindILabelProvider() f return MyLabelProvider.class; 7 g 3.1 Overview public Class<? extends IContentProvider> bindIContentProvider() f Our main design choice in developing EMF Parsley 9 return MyContentProvider.class; was to split responsibilities into small classes; this g way, customizing a single aspect of UI parts does not 11 ... g require to subclass the parts themselves, but only to customize the class related to that specific aspect. Listing 3: A Guice module with bindings. In order to handle the customized behaviors in a consistent way, we heavily use Google Guice, a 3. “Inject” one of our classes; Dependency Injection framework. With respect to 4. Customize specific aspects and configure the manual implementation of existing patterns (Gamma Guice module to use the custom implementations. et al.,