GEF Talk
From my studies of the Eclipse Graphical Editing Framework and working with some drag and drop authoring tools for the rich client platform i have some thoughts on the current authoring idea of taking the spring ide eclipse plugin and extending it to be used for sail authoring.
What i did was take an existing GEF visual editing plugin and modified to work with the current RCP demo. This is a schema diagram working with the original RCP application i wrote. This demo also has the previous modified x-men xml plugin. Check out the image below:
Looking at the picture, imagine a palette with image beans, document beans, etc... that you would beable to drag on to the canvas. For example you could drop in a video bean for video clips and an icon that looks like a tv would show on the canvas. Then you would have the ability to connect it to other beans on your canvas. Also imagine different palettes. There could be a pedagocia component palette, wise component palette, sail component palette etc....
What is the path to jump start an authoring tool?
The answer is to use existing open source plugins as a code base - if possible. For authoring we could either build the functionality from scratch or use an existing plugin like x-men editor or spring ide. Currently the spring ide plugin which does basic xml authoring and creates a read-only visual graph seems like a good place to start.
The first image is the spring xml editor. On the left there is a spring view next to the outline tab. Clicking on an element will jump to that element in the xml document in the editor on the right:
The second image is the read-only visual graph. This is created from the xml from the previous image. Its properties can be edited from the property view on the bottom. In sail authoring, all the boxes would be in the shape or icon of what that bean represents. For instance, a picture frame with a thumb nail in it would represent an image bean on the canvas.
The plugin has three main parts.
1. Xml to java editing - When editing a spring xml bean you can jump to that beans java class - very cool.
2. Grapihical representation - In which you can see a uml diagram type representation of the your spring beans xml.
3. Outline View - A view that shows you a list of beans defined in your spring xml. Also it jumps you to that bean defined in xml or to the graphical representation shown on the canvas.
From these aspects of the plugin, can we contribute back to the community with sail authoring goals in mind?
--i believe that we can contribute to these plugins with sail goals in mind, however their will be a point were our goals and their goals for the plugin will diverge. At some point, it will stop being spring ide and become the sail bean visual editor.
contributing to open source is great but our main goal is to make authoring tools for the creation and deployment of a curnit as easy and as user friendly as possible so they can be used by beginning-novice-advanced authors
From my GEF experience, i would say that the visual editing components for the editing spring beans in the spring ide have to be rewritten to become the iconic pedagogical representations that we want. The beauty of GEF is that the way the data or the model is stored is independent of how it is represented to the user. GEF implementations adhere to the MVC (Model View Controller) design pattern in which the component that displays the xml on the canvas can be swaped in and out with out modifying the component that saves the xml.
what are possible authoring tool implementation iterations?
Iteration 1: Modified spring ide visual editor with the ability to add attributes to the component, drag and drop capability.
Iteration 2: Components are represented by basic iconic boxes with editable attributes.
Iteration 3: Components are represented by advanced iconic figures. For example, a document flavored bean is represented by a scroll with user having the ability to drag text into it or open a document editor.
I believe the first iteration of the visual editing can be a modified spring ide visual editor. It is the fastest way to jump start visual editing. At this iteration we can contribute to community because we will be using and developing the plugin in its purest form. Not until iteration two will the iconic-ness or the distinct graphical nature of sail authoring will take shape requiring rewriting all spring ide visual components.
What can we give to the spring ide visual editor?
1. The ability to edit visual components and have their changes reflect in the spring xml.
2. The ability to drag an empty component on the canvas, add attributes and connect it to other components.
Where do we go from here?
Using the spring ide plugin as a "spring board" for sail authoring is a good idea. The next steps include:
1. Writing a handful of authoring sceranios
2. Writing a handful of requirements
3. Beginning implementation