Doodle, A Demo Drawing Program - Part 3
Doodle, A Demo Drawing Program - Part 3
By Guyon Roche
In Doodle - Part 2, the Doodle application gained an application framework with the document-view model. In this installment, Doodle starts to connect these components. Not much has changed visually except that once a line is drawn, Doodle allows the user to delete them by clicking on them (this will eventually be extended into a full selection mechanism).
Doodle - Part 3
Click and drag the mouse over the 'canvas' on the left to draw lines. Click on the lines to delete them.
Once again the internal workings of the Doodle code have been upated. The namespace technique has been extended and the Canvas class has gained some new subclasses to keep track of the onscreen objects.
While it may seem that the new class model has rendered the Doodle code unrecognizable, in practice, very little has changed: where once a class was created like this...
That same class is now created like this...
Where methods were assigned to the class prototype, they're now included within the methods collection, reducing a large amount of the ClassName.prototype cruft.
Start With The Document
In general, when making global changes to document-view applications, I find it helps to begin with the document as this is the focus of most of the code in the application.
The following methods (added to the Doodle.Doc methods collection) control access to the shapes collection.
It's generally good coding practice to discourage users of a class from accessing and modifying class or instance member variables directly. Allowing access to member variables creates dependencies on implementation that may be difficult to break later on. It's better to provide functions like the four above that perform the required tasks. This allows the implementation to be changed without much impact on other code.
Would You Like A Little Java With Your Script?
The next modification is the addition of a class heirarchy for Doodle document shape objects. While the Doodle application supports only one shape (at the moment), it's a good time to set up the structure of a document shape class heirarchy before things get too complicated. The ideal class name for a shape class would be simply "Shape" but there may be other shape oriented classes in the Doodle application that could be called "Shape." This will also be true as we develop the shape heirarchy further with classes like "Line, Ellipse" and so on. The solution here is to use the namespacing technique once more so that the document's shape class will be called Doodle.Doc.Shape and the graphics library's shape will be JSX.Graphics.Shape.
The name field here isn't the fully qualified 'Doodle.Doc.Shape' but simply the short name 'Shape' which descendants from the document shape class will use to uniquely identify this class.
Notice also the "Types" element in the statics collection. The purpose of this is to act as an enumeration of different shape types. Each item in the object literal equates a name with a number. By convention, the name (e.g. LINE) is written in uppercase. Since it's included in the statics collection, the Types enumeration will be added as a property of the Doodle.Doc.Shape class itself and not to the class prototype so it can be accessed easily without requiring a Shape instance. So far there's only one shape type enumeration, but as each new shape type is added, a new enumeration value will be included here.
The Shape class maintains a numerical ID value which will be used to distinguish between different shape instances.
The document Line class now inherits from Shape. Inheritance is specified by adding a base class link in the class definition.
Notice that with the inheritance model used in this code, the Line constructor must call the Shape constructor explicitly since this isn't done automatically by the inheritance model. This gives the Line class the opportunity to choose alternate arguments to be passed to the Shape base class.
Created: October 13, 2006
Revised: November 29, 2006