model driven web app demo

In this demo I show how you might use Gem to create a model driven web application. I think it would be interesting to investigate pairing this with OSGi running on Amazon EC2.




Update:

I first described how the UriLayer/SegmentLayer worked back in January. Since then the details have changed a bit. The key points are described below:

• URI segment names can be established by using a word prefixed with ~ at the beginning of a group. So [~foo a b c] causes the segment name of the group to be foo. The change from January is that it was foo~ (suffix instead of prefix) back then. Arguably, /foo or foo/ would be a clearer way of indicating segment name.
• In the demo I forgot to talk about the '!' character. This is used to indicate the point at which you move from the filesystem into the model (in EMF terms, it's perhaps like going from the EResource to one of the logical elements - like an EPackage - inside the resource).
• To continue with the last point
• /demo/site.gem identifies a model file (or just some arbitrary file).
• /demo/site.gem! identifies the Model element (the root node in the model).
• /demo/site.gem!/ identifies the Figure inside the Model.
  
• /demo/site.gem!/foo identifies a Site with segment name 'foo' inside the root Figure.
• /demo/site.gem!/foo/ identifies the Figure inside the above Site.
• So note from above that the trailing / always indicates a Figure (whereas in January it always indicate a Site).
  

Using Gem as a simple presentation engine

This demo shows how Gem can be used to create simple presentations.

Walkthrough of implementing a Gem layer

Demo part 1:


Demo part 2:

Demo of new visual layers

Since the first series of posts in January I've been slowly working on a new set of layers that comprise a simple visual editor for Gem models. Here is a first look at the new stuff:



I talk about several layers in the demo. Here is a quick summary of them:

• FrameLayer - Manages size and position information of visual elements. Supports mapping raw coordinates to the "most appropriate" (deepest) element.
• ShapeLayer - Performs layout and drawing of the view. Can be extended to support a variety of layout and draw methods.
• SelectionLayer - Keeps track of the currently selected element. (Forgot to mention this in the demo.)
  
• MouseEventLayer - Handles raw mouse events received by the SWT canvas and forwards them to the most appropriate ShapeFacet for handling.
  
• KeyEventLayer - Handles raw key events and directs them using the current SelectionFacet.
• GraphvizLayers - Render sections of the model as "interesting" graphs using graphviz.
  

The SegmentLayer and UriLayer

Another layer idea I've been playing with is the UriLayer. The basic idea here is to give every Faceted part in the model a hierarchical path-based URI. This will allow for another way of modeling relationships (by embedding URIs in models, similar to how we did it with "spans" in the SpanLayer) and can serve as a basis for inter-model references (or external references to model parts).

Here again I'll assign bits of the Gem syntax to assist. If the first child in a Group or Root element is a Word that has a ~ suffix, then it will be treated as the segment of the URI path for the Group or Root element, otherwise the segment will just be the index number of the Faceted part.... Ok that sounds a bit complicated, so here's the text for a model:

foo~ (barX~ a b [baz~] ) (barY~ b)

and here's a look at the model:



So the idea is that foo~, barX~, etc. are Words with the ~ suffix and appear first in their Group, therefore they have been used to name the SegmentFacet of their Group. The SegmentFacets that don't get a name this way simply get a number instead.

The UriLayer itself simply gives us a view of the URI assigned to every Faceted part by walking up to the Model part and concatenating each SegmentFacet value on the way:



The images above are showing Figures but not Sites. Let's look at both for the SegmentLayer:



So all Sites have '/' as the SegmentFacet value except for the Model which has '!'. The idea here is that if the Environment is asked to resolve a URI it can split it around the '!' and look at the first part to find a model and then hand the second part to the model's UriLayer to resolve in the context of that model.

The vague plan...

I've thought about adding an abstract UriQueryLayer where its UriQueryFacet would have a method like handle(String uriQuery). This would allow for resolving a URI (with the UriLayer) and handing the parameters to the resolved part to do .... whatever (you would subclass UriQueryFacet to provide domain-specific implementations).

With this group of layers you could imagine using a model to power a servlet. Incoming URLs could be directed to a UriQueryFacet for processing. The behavior of this servlet can vary based on the structure of the model (used to encode state) and the implementation of the UriQueryFacet (used to encode behavior).

blog filter: Epsilon and Glimmer

Here are two blog posts pulled from Planet Eclipse this week that relate somewhat to my quest for modeling language nirvana (whatever that means).

First is about a very cool looking Eclipse GMT subproject called Epsilon. The post is about how Epsilon can transform from HUTN to EMF (HUTN is a spec that outlines a general purpose textual syntax for describing models). See the linked screencast demo. Also mentioned are xText and TCS - two textual modeling / DSL systems in the Eclipse modeling project orbit.

The second post is about Glimmer. (And it makes the bold, but somewhat dubious claim that 'XML is dead'. Don't we wish!). Glimmer looks like a simple declarative syntax for SWT screen layout. I thought this was cool because I've been generating graphviz's DOT syntax from Gem and it would be similarly easy to generate Glimmer.

The SpanLayer

In this post I'm going to continue two threads from previous posts.

First, I mentioned previously that I think of modeling as object-orientation with first-class relationships between the objects and I talked about the containment relationship which is built into the lattice metamodel. In this post I want to talk about implementing another kind of relationship as a layer called the SpanLayer.

Second, I've described the Gem syntax and noted that it has no pre-assigned semantics. Here I'm going to reach into this toolbox of syntax and begin assigning meaning to it.

The idea of the SpanLayer is to build a hashtable that maps some of the facets to others. We will interpret the ` (back-tick) prefixing a Word as designating the target (or end-point) of a "span" and the ~ (tilde) prefixing a Word as designating the source (or start-point) of a span.

Let's look at an example:



The text for the above model looks like this:

`foo `bar [ a b ~foo (c ~bar ~foo) ]

The SpanLayer shown in the diagram is simply highlighting the sources and targets of the spans by blanking out the text for the facets that aren't related to spanning. This is ok for a start, but it would be better to show spans more like this:



Here the span targets are shown with a different shape and the spans themselves are drawn from source to target. This FancySpanLayer was built on top of the SpanLayer. It uses the raw span information provided by the SpanLayer and renders it in a more sensible way.