Two days ago was the Helios DemoCamp in Darmstadt at Deutsche Telekom.  I think it was a very successful evening with a whole bunch of good talks. Two of them are very noteworthy.

The first one was presented by Marcel Bruch. He talked about the Eclipse Code Recommenders project which he’s working on at TU Darmstadt. The basic idea behind this project is to provide a way to recommend code. He used the analogy of the Amazon online store. When you buy a book you always get a recommendation along the lines of, “People who bought this book also found this one interesting…”. The Code Recommenders does exactly the same just with code.  Watch the great screencast the Code Recommenders Team provides if you don’t want to take my word for it.

Another especially noteworthy demo for me was presented by Stefan Lay. He demo’d the Eclipse Git Team provider called EGit.  In addition to the tooling he presented Gerrit. Gerrit is an automated review tool for Git. The scenario he presented was to push some changes to a remote repository. The changes were caught by gerrit to be reviewed.   With those changes however, an automated build failed and gerrit sent an automated message that the changes couldn’t be applied because they broke the build. I think this will make the workflow much easier for code review and keeping the repository stable. The EGit project already uses Gerrit for their productive work.

To put it all in a nutshell it was a very cool DemoCamp with 120 attendees and nice buffet afterwards. At this point I want to thank Ralph Müller and the Foundation who organized a spontanous Eclipse Stammtisch after the DemoCamp. It was great to talk to all the guys individually. The bad thing about this is that the evening went by too fast. But there also a good thing. Most of those people will also attend the Eclipse Summit Europe in November and we can meet again.

Tags: democamp, eclipseRT, egit, equinox, helios, rap, rcp, swt, talks

Did you ever wanted to know how features find their way into Eclipse and became a part of a huge release like Eclipse Helios? What role do committers play? What is the part of the community? How do different projects collaborate with each other?

For all of you Benjamin Muskalla and I will give the answer on the Eclipse Helios DemoCamp in Darmstadt on July the 14th. If you are around feel free to step by.

Tags: democamp, eclipse, emf, helios, rap

As part of the new Eclipse Helios, the Rich Ajax Platform project released version 1.3. If you’d like to know what is new in RAP 1.3, here’s a short screencast.

You can find a more detailed version on the RAP 1.3 New and Noteworthy page.

Thanks to the community for all the hard work that made this great release possible.

Of course, we are currently making plans for RAP 1.4, which will be part of Indigo. Therefore,  we started a discussion on the plan items on our newsgroup. We’re looking forward to another great year with Indigo.

Tags: eclipse, eclipse rap, eclipseRT, helios, indigo, rap

Did you ever want to know what the Rich Ajax Platform is without spending too much time on it? For all of those we did a screencast that shows what RAP is in about a minute.

You’ll also find the video on the RAP project page.

Tags: eclipse, eclipse rap, helios, rap

Tags: eclipse rap, iAd, IPad, iphone, protocol, rap

Based on your feedback on my last blog posts, I’ve implemented a first prototype of the RAP protocol. Here’s an update on the current state. Several functions are now implemented e.g. server side message creation, client side message processing, client side message creation and server side message processing. The cool thing about all this stuff is that it works already with the RAP lifecycle. To demonstrate the use of the protocol, I migrated the Shell widget. You can see the results in the screenshots below.

The first screenshot shows the protocol based shell. You can see that FireBug is open and is showing the JSON response from the server. The second screenshot shows a JSON request that was sent from the client to the server. The current protocol implementation is a hybrid, which means that it uses JavaScript and protocol messages. With this hybrid it’s possible to run the RAP workbench on top of the protocol based shell.

If you want to test this shell yourself you can use the RAP protocol git mirror which can be found on github. At the github wiki you can see what bundles you’ll need to run the protocol based shell. To start the protocol shell just run the launch configuration within the org.eclipse.rap.rwt.protocol.playground bundle. The code for the protocol is in a very early state, so please be warned that there could still be drastic changes in the code base.

The next step in the development of the protocol will be to test it on a different client technology. For this purpose a demo for the iPad would be the perfect candidate. AdLib is a JavaScript library which brings native like widgets to the iPad’s mobile safari browser. And, I think it will be possible to use this library with RAP and the protocol. I will keep you posted on the progress of the iPad demo. Looking forward to your feedback.

Tags: eclipse rap, eclipseRT, protocol, rap

As I described in a previous blog I’m going to create the tooling for creating equinox based war files within this year’s gsoc. For this purpose I created some UI sketches with the WireframeSketcher. You can see the first thoughts on the UI below. I would appreciate if you can give some feedback on the sketches to improve the tooling. You can find more information about the war products at the wiki page.

• the new wizard

• the warproduct editor

• the export wizard

Tags: eclipse rap, eclipseRT, equinox, OSGi, rap, soc, war deployment

In my last blog I talked about the messaging format which will be used for the RAP protocol messages. I told you that we plan to use JSON as the message format. So, the thing is that the blog ended in a little discussion about what are the benefits of using JSON instead of XML. So, I decided to pick the biggest argument which speaks for XML and try to mitigate it

I want to talk about XML-Schema. XML-Schema is a really great benefit of XML. You can use XML-Schema to describe a XML-Message for validation. Another benefit of XML-Schema is that you can write your schema completely with XML.

When it comes to the discussion why somebody wants to use JSON instead of XML, the schema is always an argument against JSON. But this has now an end. There is a young project out there called JSON Schema. With JSON Schema you can define your message completely with JSON. For sure the JSON Schema is not so well-engineered as XML-Schema at the moment. But I think we need to give it a chance to grow. The guys behind JSON Schema are doing a great job with this technology and are working very hard to make this technology ready for productive use. There are already some implementations of JSON Schema. But enough about the theory, lets take a look at the schema for the protocol message described here:

{
  "description" : "RAP protocol message schema",
  "type" : "object",
  "properties" : {
    "meta" : {
      "description" : "Contains request sepcific information",
      "type" : "object",
      "properties" : {
        "requestCounter" : { "type" : "integer", "minimum" : 1 },
        "settingStore" : { "type" : "integer" },
        "tabId" : { "type" : "integer", "optional" : true }
      }
    },
    "device" : {
      "type" : "object",
      "description" : "Contains display specific information.",
      "optional" : true,
      "properties" : {
        "id" : { "type" : "string" },
        "cursorLocation" : {
          "type" : "array",
          "maxItems" : 2,
          "items" : { "type" : "integer" }
        },
        "focusControl" : { "type" : "string" }
      }
    },
    "widgets" : {
      "type" : "array",
      "description" : "Contains widget specific information.",
      "uniqueItems" : true,
      "minItems" : 1,
      "items" : {
        "type" : "object",
        "properties" : {
          "widgetId" : { "type" : "string", "optional" : true },
          "type" : { "type" : "string", "enum" : [
            "synchronize",
            "multiSynchronize",
            "listen",
            "construct",
            "fireEvent",
            "destroy",
            "execute",
            "executeScript" ]
          },
          "payload" : { "type" : "object" }
        }
      }
    }
  }
}

As with the message itself the most interesting part in the schema is the “widgets” property of the “message” object. It’s very important that it’s an array instead of an object because of the event order which will be send to the RAP server. So, with the JSON Schema we have the possibility to define this property as an array and we can be sure that it’s an array at runtime. Another cool thing is that we can define that all array elements has to be an object with some required properties. For example every widget array element needs a property called “type” for identifying it’s payload. The schema gives us the possibility to define allowed values for the “type” property. So, we can be sure that a message only contains allowed payloads.

I think describing the whole schema will blow up this blog. So, take a closer look at the schema by your self if you are interested and write a comment if something is not clear.

At the moment it’s not clear if we use the JSON schema for the protocol at runtime. But it’s always good to know that we have something for validation. So, let me know what do you think about the schema.

Tags: eclipse rap, protocol, rap

In a previous blog I talked about the functionality that a RAP protocol message should provide. I also introduced you to the requirements of a message. A message should take care about the following tasks: Construction, Destruction, Synchronization, Eventlistener, Events, Methods and Scripting (look at this blog for more details). Additional a message should provide request and display relevant information. So, I decided to search for a messaging format which is able to bring the described information into one message. The result of this search is JSON. JSON is a very lightweight messaging format defined by Douglas Crockford and eliminates the drawbacks of XML. The cool thing about JSON is that it’s really fast to parse a message and it’s very readable by humans. Another cool thing is that it fits all needs of the RAP protocol. So, now lets take a look at a sample protocol message:

{
  "meta" : {
    "settingStore" : 123486875,
    "requestCounter" : 6,
    "tabId" : 4
  },
  "device" : {
    "id" : "w1",
    "cursorLocation" : [ 214, 544 ],
    "focusControl" : "w34"
  },
  "widgets" : [
    {
      "widgetId" : "w23",
      "type" : "synchronize",
      "payload" : {
        "prop1" : "value1",
        "prop3"	: "value2"
      }
    },
    {
      "widgetId" : "w33",
      "type" : "listen",
      "payload" : {
        "selection" : true,
        "focus" : false
      }
    },
    {
      "widgetId" : "w24",
      "type" : "construct",
      "payload" : {
        "parent": "w33",
        "widgetType" : "org.eclipse.swt.Text",
        "style" : [ "BORDER", "FLAT" ],
        "parameter" : [ "eins", 2, true ]
      }
    },
    {
      "widgetId" : "w25",
      "type" : "fireEvent",
      "payload" : {
        "event" : "focus-in"
      }
    },
    {
      "widgetId" : "w26",
      "type" : "destroy",
      "payload" : null
    },
    {
      "widgetId" : "w27",
      "type" : "execute",
      "payload" : {
        "method" : "someName",
        "parameter" : [ "value1" , "value2" ]
      }
    },
    {
      "widgetId" : "w44",
      "type" : "executeScript",
      "payload" : {
        "scriptType" : "text/javascript",
        "script" : "var wm = org.eclipse.swt.WidgetManager.getInstance();"
      }
    }
  ]
}

The above message example shows an imaginary RAP message. The sample make no differences between request and response. Now lets take a closer look at the meaning of the message.

As you can see the whole message is represented as one JSON object. Let us call this object the “message” object. The message object has three properties: “meta”, “device” and “widgets”. Two of these properties are also represented as objects. The “meta” and “device” objects are simple property maps for the request and display specific information. The interesting part of the “message” object is the “widgets” array. As you can see the array is an object array. This means the containing array properties are JSON objects. With the use of an array instead of an object we can bring an order to the containing information which is needed for reproducing e.g. an event order on the server side. Each object in the array represents one widget payload. The payload types map the needed functionality. The following payloads are valid:

• synchronize: For synchronizing widget properties.
• listen: For adding a listener to a client side widget.
• construct: For creating widgets on the client side.
• fireEvent: For firing client side events.
• destroy: For disposing client side widgets.
• execute: For calling a method on a client side widget.
• executeScript: For executing native script code.

Each object in the widget array has three properties. First the “widgetId”. The id is needed to identify the client side counterpart of a widget. The second property is the “type” of the payload (one of the seven above). The “type” property identifies the content of the “payload” property. The “payload” property is normally another JSON object which has “type” specific properties. For example a “widgets” array object of the type “synchronize” holds a map of properties within it’s “payload” object. I think the other types are almost self-explanatory.

I think this is a very straight forward message structure which makes it very easy to understand messages that are sent from the RAP server to the client and the other way around. For sure you have to understand JSON. But I think JSON is very easy to understand and widely used across the web. So, in my opinion JSON is the right choice for the messaging format. With JSON we can completely wrap the required information and it’s free of any meta overhead. Another pro for JSON is very obvious when you look at a message that’s currently sent from the RAP server to the client. So, the described example message is much more meaningful than the RAP generated JavaScript code listed below (normally it’s all in one line).

var wm = org.eclipse.swt.WidgetManager.getInstance();
wm.dispose( "w306" );
var req = org.eclipse.swt.Request.getInstance();
req.setRequestCounter( "3" );
var w = new org.eclipse.rwt.widgets.ToolItem( "check", false );
wm.add( w, "w317", false );
var t = wm.findWidgetById( "w286" );
t.addAt( w, 0 );w.setText( null );
w.setImage( "rwt-resources/35.fwk14856315/icons/ttt.gif", 16, 16 );
w.setSpace( 0, 24, 0, 22 );
w.setHasSelectionListener( true );
wm.setToolTip( w, "Filter all leafs" );

To improve the message quality let me know what do you think about the described format please. Any feedback is very welcome. As a next step I will create a prototype for creating this kind of messages in the context of RAP. I will talk about the structure of this generator as soon as I have results

Tags: eclipse rap, protocol, rap

After another 6 weeks of working hard towards the Helios Release, we are one step closer. RAP 1.3 M7 for Eclipse 3.6 is out. From the new features, here are my personal top three:

1. Eventually, a GraphicsContext implementation that lets you draw onto the browser using SWT API! In the early days of RAP, we regarded this as being impossible.
   
2. Animations support in CSS enables cool effects like sliding menus, fading tooltips, and more.
   
3. Vertical-only grid lines make Tables with alternating row colors look much clearer. I had this feature on my todo list for almost one year.
   

• Check out the complete New and Noteworthy for M7.
• Get RAP M7 from the RAP download site or
• Get the M7 Eclipse for RCP/Plug-in Developers package that includes everything you need to develop RCP and RAP applications.

Tags: eclipse rap, helios, new and noteworthy, rap