I've completed this week the "grammar to Ecore-model" converter plugin, and had even time to write a chapter about it in the (draft) progress report for my Google SoC project :)

A small experiment in diagram-layout-from-AST

If the previous post sounded too vaporware to you, this time you'll see code snippets for a view that auto-layouts the EPackage contents of a selected EClass, for example in the Ecore Sample Editor. OK, right away I want to mention that this code is my HelloWorld 0.1 attempt at layouting. If you're already into programming diagram editors, stop reading this post!!!



Most of the setup code for the view in question comes from a plugin to visualize OCL Abstract Syntax Trees, an article about which you can find here.

Instead of using a TreeViewer, this time I'm using a GraphViewer, courtesy of Zest, the Eclipse Visualization Toolkit. Again, I'm using Zest in a most basic manner, you'll see the moment you visit Zest's homepage that it's way more powerful than what my example conveys.

In a lucid moment I realized that in order to customize the figure to display (a class figure) an IStylingGraphModelFactory should be provided, like this one:

public class EcoreGraphModelFactory extends GraphModelFactory {   public EcoreGraphModelFactory(AbstractStructuredGraphViewer viewer) {     super(viewer);     // TODO Auto-generated constructor stub   }   @Override   public GraphNode createNode(Graph graph, Object element) {     GraphNode gn = super.createNode(graph, element);     if (element instanceof ENamedElement) {       IFigure cf = createFigure(element);       Dimension s = cf.getSize();       gn.setCustomFigure(cf);       gn.setSize(s.width, s.height);     }     return gn;   }   private IFigure createFigure(Object element) {     IFigure res = null;     if (element instanceof EClass) {       res = createEClassFigure((EClass)element);       // res = UMLExample.createClassFigure1();     }     return res;   }      private IFigure createEClassFigure(EClass eC) {     Font classFont = new Font(null, "Arial", 12, SWT.BOLD);     Image eCImage = Activator.getImage(eC);     Label classLabel1 = new Label(eC.getName(), eCImage);     classLabel1.setFont(classFont);     UMLClassFigure classFigure = new UMLClassFigure(classLabel1);          for (EAttribute eA : eC.getEAttributes()) {       String str = eA.getName() + " : " + GenericsUtil.getText(eA.getEGenericType());       Label attributeL = new Label(str, Activator.getImage(eA));       classFigure.getAttributesCompartment().add(attributeL);     }          for (EReference eR : eC.getEReferences()) {       String str = eR.getName() + " : " + GenericsUtil.getText(eR.getEGenericType());       Label attributeL = new Label(str, Activator.getImage(eR));       classFigure.getMethodsCompartment().add(attributeL);     }          classFigure.setSize(-1, -1);     return classFigure;   } }

All in all, the plugin structure is as follows:


You can find (at your own risk, no support, thanks) the Eclipse project in question in this zip file.

I don't even dare call it a "proof of concept", but anyway I felt some code should be thrown in to support my argument.

The IDE generator I'm working on should provide an extension point to let querying the current AST, to support this and other use cases. Yes. I think so.

diagram layout out of textual representation

How to cook your own DSL language. That’s what most DSL tool suppliers want you to do right away, don't they? I say: no problem, but please notice there’s already a plethora of languages (and their notations) that you could leverage, gain experience from, and then move on to design your own brainchild. Examples follow.

Consider statecharts. Diagrams are nice to browse, but hard to edit. Let’s say we have an IDE for a textual notation of statecharts. I like this comparison [1]:


Which is faster?

textual Environment:
1 move cursor to position
2 type “|| await C”

graphical Environment:
1 make room: shift neighbor states, enlarge parent state
2 click on “add state”
3 move mouse to location and place new state
4 click on “add state”
5 move mouse to location and place new state
6 double click on new state, toggle terminal field
7 click on “initial state”
8 move mouse to location and place new initial state
9 click on “transition”
10 move mouse to location of initial state
11 press left mouse button and keep pressed until reaching state
12 click on “transition”
13 move mouse to location of state
14 press left mouse button and keep pressed until reaching terminal
state
15 double click on transition
16 write “C” in trigger field
17 press “OK”
18 click on “delimiter line”
19 move mouse to location and place delimiter line


The underlying argument is that having a true DSL infrastructure, including access to the Abstract Syntax Tree (AST) of the doc being edited, gives you a lot of mileage, e.g. enabling the suggested use (auto-layout).

There's more related work, of course (the idea cannot be new), but I don't see it being mentioned often enough in DSL tooling circles. Diomidis Spinellis has a nice prototype to layout UML class diagrams from Java source, to achieve things like:

given the following input:

// Author:  Vadim Nasardinov
// Version: $Id: ceg-mv.xml,v 1.1 2005/11/23 22:21:22 dds Exp $

import java.util.List;
import java.util.Map;

/**

 * @assoc "1..1" - "0..n" Adapter
 * @assoc "" - "0..n" ObjectType

 * @assoc "" - "0..n" ObjectMap
 * @assoc "" - "0..n" Table
 * @assoc "" - "0..n" DataOperation

 **/
class Root {
  private Map m_adapters;
  private List m_types;
  private List m_maps;
  private List m_tables;
  private List m_ops;

  public Adapter getAdapter(Class klass) {}
}


class Adapter {
  public Root getRoot();
}

abstract class Element {
  Root getRoot() {}
}

class ObjectType extends Element {}


/**
 * @has "1..1" - "1..1" ObjectType
 **/
class ObjectMap extends Element {
  private ObjectType m_type;
}


class Table extends Element {}

class DataOperation extends Element {}

Notice that it's possible to generate different diagram views from the same source description.

Actually, all this detour into diagrams actually aims at reinforcing the view that language engineering (by means of metamodeling, with well-formedness and type-checking conditions specified in OCL) is a good thing, that also comes to benefit in case you're all for diagrams. But I won't peruse any further this visual path, for that you can check two generators of diagram editors:

1. the Eclipse Graphical Modeling Framework
   
2. the Tiger Project at Tech Univ Berlin (Germany)
   

Have fun (and please come back to this textual DSLs blog soon :)

References:

[1] The Kiel Statechart Layouter

existing prototypes

I'm quoting from a presentation I gave on this topic:

• xText by the OpenArchitectureWare team
  
• TCS, by Frédéric Jouault (INRIA)
  
• TEF, by Markus Scheidgen (Uni Humboldt)
  
• Gymnast, by Chris J Daly (IBM)
  
• SAFARI (just about to become an Eclipse project)
  

Actually each of them has its unique approach towads jumpstarting a toolset for a custom DSL. Comparison would be a lengthy, lengthy, affair. I can sum it all up by saying that, provided your requirements fit the design criteria of your tool of choice, they'll save you a lot of work.

A hard test for any IDE generator for a custom DSL is whether the input specification encodes more constraints than just grammar (I'm talking about well-formedness rules such as declarations-before-usages and type-checking rules. Same observations go for other tools not on this list). More details on this criteria can be found in the aforementioned presentation.

APIs for programming text editors

An important aspect of my project involves the mechanics of programming a text editor under Eclipse. I must say that I haven't found a comprehensive tutorial on this (if there ever can be). If all goes well with my project, even less people will need to know about these APIs :) In the meantime, helpful docs include:

• A talk at EclipseCon 2004, Text Editors and How to Implement Your Own by Kai-Uwe Mätzel
• The EclipseCon 2006 tutorial Text Editor Recipes (by Tom Eicher and Martin Aeschlimann) and its slides
  

Don't worry! More references will come later! (and will be available as URLs in commented source code). Want tutorials? I've found these useful:

• http://www.realsolve.co.uk/site/tech/jface-text.php
  
  
• http://wiki.eclipse.org/index.php/Eclipse_FAQs#Text_Editors

how it all started

The original reason to start this blog is leaving a “paper trail” of my design decisions around a project I’ve started,

Provide an Eclipse IDE generation environment derived from a language grammar

What’s it about? First go to the ongoing Google Summer of code (2007) projects for Eclipse . From there, just dig into this project description

The motivation for the whole thing is lowering the learning curve to tooling a custom DSL. For example, a DSL more readable than BPEL, or a DSL that wall-papers over the many EJB3 APIs, and so on. It’s not that difficult to design one’s own DSL (especially if one pays attention to abstract syntax, well-formedness rules, and type checking, all achievable with metamodeling and OCL). What’s missing then is the IDE for one's brainchild.

There’s growing interest in Domain Specific Languages (fuelled by Model Driven Architecture). Martin Fowler describes in “A Language Workbench in Action” the kind of DSL definitions that current tools support, plus or minus some features.
http://www.martinfowler.com/articles/mpsAgree.html

Before starting this project I just wanted to be a user of (let’s call it) language engineering technology. So I reviewed what research teams with a lot of experience had to offer for Eclipse, and I realized that my needs were not high in their priority list. In the end, someday that will change, so check from time to time what’s new at places like: http://www.meta-environment.org/ and http://harmonia.cs.berkeley.edu


Back to my project. From the start, I can identify two problem areas:

1. the mechanics of programming a text editor under Eclipse, and
2. other prototypes nearby this technology niche
   

that are described in more detail in the next two blog entries.