Scalable Vector Graphics - The Next Generation?

I had the opportunity of working in a relatively new (supposedly cutting edge) technology called Scalar Vector Graphics in my new project. IT has been great up until now. SVG is a language for describing two-dimensional graphics and graphical applications in XML. This XML could be either an external file or an inline XML. SVG has some primary inbuilt support in Firefox and for the lousy Internet Explorer there's the Adobe SVG Viewer.

When we started out with the project which was about drawing stuff(shapes and figures) in a canvas collaboratively, we were unsure about what to use. Since we needed the users to draw polygons and drag and drop objects (images that represent objects) to these polygons (and identify this region ), we were looking for some high end stuff. Indraneel suggested the use of SVG and before that I had very little or no knowledge of SVG. Reading about SVG and understanding it took some time but when it was known that the programming would be done in Javascript I was quite comfortable.

Javascript is used to manipulate the drawing of regions and dragging and dropping of items on these regions. The first wrapper Javascript library I saw was based on JQuery. I started out doing some POC using this library, but JQuery is not my style of coding. I like the operator/operand/manipulation style of coding which I think Prototype provides. So I went on to find another library thats based on Prototype called Prototype Graphic. I found this library excellent and fulfilled all of my needs. The sample files helped a lot in understanding the things I could do with this wonderful library.

The server side of the application was done by Dan and the client side (HTML/ Javascript/ CSS) was done by me. I tried to structure the application code in a class style as done with Workstreamer. Base application, managers like Layermanager, Layertreemanager, Usermanager etc. I had to also do a lot of changes in the main Prototype Graphics Javascript files, like adding node elements to the base SVG.

The Application.js file has all the base methods and initialization. This also meant uderstanding the stage of the game (plan, play, postprocessing) and setting up the item necessary for each stage. It also had hooks (event methods) so that all the data structures could be updated. This might be something like when a new object is created what methoids must be called so that the data is updated in the server.

The application dealt with the creation of layers (a collection of regions) and regions (with is a polygon shape). A Layermanager.js file was created with maintains the list of layers which inturn would have a list of regions. Each region would have a shape associated with it so that highlighing ( displaying the border with a different color) is possible. The regions would essentially have a set of co-ordinates (x and y) and this co-ordinates would be feeded to the server when the user is reday to create his game. Methods for hiding a layer(which meant hiding all the regions inside a layer), showing a layer etc were added.

The layers and regions had to presented to the user in some way. I felt a tree would be fit this requirement perfectly. Each layer would/could have regions as children and they could be renamed (labelled). An id (generated from inside the layermanager) would bbe assigned to each layer/region on creation and that would be its base identifier. Now for the tree I started out with the Yahoo! tree, but soon had to change it because of its clash with the JQuery code which was inserted by the server. The clash with Prototype was solved using jQuery's no conflict option. Aditya did his POC and gave me the TafelTree implementation which was based on Prototype. Hooks were added so that on selecting a region, the region would be highlighted on the canvas and on selecting a layer, that layer (ie the regions inside that layer) would show and all the others would be hidden.

The Draggablemanager.js file was the base file used to create the objects on dragging and dropping. The canvas would have a palette (an area which will have objects which could be initialized by dragging and dropping into the droppable area). Dragging from the palette would actually clone the object being dragged, add all the necesaary classes to identify the newly created object and after the drop was done would issue the create object command. To identify the object moved to created a class was added. All the updates to the canvas was done using a full refresh of the canvas. The server implemented using a framework called Lift would facilitate this. The refresh is done by lift comet calling a pre defined Javascript function which would refresh (redraw) the game board. The selection of items (for delete, lock, unlock) was done by drawing a circle around it after the object (which is in the canvas) was clicked. Double clicking on the item would fire a modal window inside the browser where the user could update the label and description for the item.

The regions inside a layer would have a fill ( color inside the polygon) which is the same. ie Different layers would have different fill colors. This color was maintained byt inserting this information in cookies. As the canvas was constantly refreshed, randomizing the color everytime felt odd. Therefore the code was stored inside cookies and therefore cookie,js was used.

A carousel control was used to show the backgrounds/objects available to the user during planning. The coding done for this control was one of the best I have seen. It took me some time to actually understand what Victor had done with this.

A gamecreator was created so that the game definition JSON could be generated and passed to the server during the game plan phase. This also had methods to update the background image, game name and description.

The chat feature was one feature that I felt increased the level of collaboration in this product. The comet from the Lift made this possible. The Usermanager was created to maintain the list of users, identify the current user and his privileges, and populate the chat messages in the necessary container.

Ill be writing more about the coding aspect in the next post !