index.txt 12 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316
  1. Document: API Specification
  2. Overview:
  3. This JavaScript library is divided into 8 packages. The top-level <mxClient>
  4. class includes (or dynamically imports) everything else. The current version
  5. is stored in <mxClient.VERSION>.
  6. The *editor* package provides the classes required to implement a diagram
  7. editor. The main class in this package is <mxEditor>.
  8. The *view* and *model* packages implement the graph component, represented
  9. by <mxGraph>. It refers to a <mxGraphModel> which contains <mxCell>s and
  10. caches the state of the cells in a <mxGraphView>. The cells are painted
  11. using a <mxCellRenderer> based on the appearance defined in <mxStylesheet>.
  12. Undo history is implemented in <mxUndoManager>. To display an icon on the
  13. graph, <mxCellOverlay> may be used. Validation rules are defined with
  14. <mxMultiplicity>.
  15. The *handler*, *layout* and *shape* packages contain event listeners,
  16. layout algorithms and shapes, respectively. The graph event listeners
  17. include <mxRubberband> for rubberband selection, <mxTooltipHandler>
  18. for tooltips and <mxGraphHandler> for basic cell modifications.
  19. <mxCompactTreeLayout> implements a tree layout algorithm, and the
  20. shape package provides various shapes, which are subclasses of
  21. <mxShape>.
  22. The *util* package provides utility classes including <mxClipboard> for
  23. copy-paste, <mxDatatransfer> for drag-and-drop, <mxConstants> for keys and
  24. values of stylesheets, <mxEvent> and <mxUtils> for cross-browser
  25. event-handling and general purpose functions, <mxResources> for
  26. internationalization and <mxLog> for console output.
  27. The *io* package implements a generic <mxObjectCodec> for turning
  28. JavaScript objects into XML. The main class is <mxCodec>.
  29. <mxCodecRegistry> is the global registry for custom codecs.
  30. Events:
  31. There are three different types of events, namely native DOM events,
  32. <mxEventObjects> which are fired in an <mxEventSource>, and <mxMouseEvents>
  33. which are fired in <mxGraph>.
  34. Some helper methods for handling native events are provided in <mxEvent>. It
  35. also takes care of resolving cycles between DOM nodes and JavaScript event
  36. handlers, which can lead to memory leaks in IE6.
  37. Most custom events in mxGraph are implemented using <mxEventSource>. Its
  38. listeners are functions that take a sender and <mxEventObject>. Additionally,
  39. the <mxGraph> class fires special <mxMouseEvents> which are handled using
  40. mouse listeners, which are objects that provide a mousedown, mousemove and
  41. mouseup method.
  42. Events in <mxEventSource> are fired using <mxEventSource.fireEvent>.
  43. Listeners are added and removed using <mxEventSource.addListener> and
  44. <mxEventSource.removeListener>. <mxMouseEvents> in <mxGraph> are fired using
  45. <mxGraph.fireMouseEvent>. Listeners are added and removed using
  46. <mxGraph.addMouseListener> and <mxGraph.removeMouseListener>, respectively.
  47. Key bindings:
  48. The following key bindings are defined for mouse events in the client across
  49. all browsers and platforms:
  50. - Control-Drag: Duplicates (clones) selected cells
  51. - Shift-Rightlick: Shows the context menu
  52. - Alt-Click: Forces rubberband (aka. marquee)
  53. - Control-Select: Toggles the selection state
  54. - Shift-Drag: Constrains the offset to one direction
  55. - Shift-Control-Drag: Panning (also Shift-Rightdrag)
  56. Configuration:
  57. The following global variables may be defined before the client is loaded to
  58. specify its language or base path, respectively.
  59. - mxBasePath: Specifies the path in <mxClient.basePath>.
  60. - mxImageBasePath: Specifies the path in <mxClient.imageBasePath>.
  61. - mxLanguage: Specifies the language for resources in <mxClient.language>.
  62. - mxDefaultLanguage: Specifies the default language in <mxClient.defaultLanguage>.
  63. - mxLoadResources: Specifies if any resources should be loaded. Default is true.
  64. - mxLoadStylesheets: Specifies if any stylesheets should be loaded. Default is true.
  65. Reserved Words:
  66. The mx prefix is used for all classes and objects in mxGraph. The mx prefix
  67. can be seen as the global namespace for all JavaScript code in mxGraph. The
  68. following fieldnames should not be used in objects.
  69. - *mxObjectId*: If the object is used with mxObjectIdentity
  70. - *as*: If the object is a field of another object
  71. - *id*: If the object is an idref in a codec
  72. - *mxListenerList*: Added to DOM nodes when used with <mxEvent>
  73. - *window._mxDynamicCode*: Temporarily used to load code in Safari and Chrome
  74. (see <mxClient.include>).
  75. - *_mxJavaScriptExpression*: Global variable that is temporarily used to
  76. evaluate code in Safari, Opera, Firefox 3 and IE (see <mxUtils.eval>).
  77. Files:
  78. The library contains these relative filenames. All filenames are relative
  79. to <mxClient.basePath>.
  80. Built-in Images:
  81. All images are loaded from the <mxClient.imageBasePath>,
  82. which you can change to reflect your environment. The image variables can
  83. also be changed individually.
  84. - mxGraph.prototype.collapsedImage
  85. - mxGraph.prototype.expandedImage
  86. - mxGraph.prototype.warningImage
  87. - mxWindow.prototype.closeImage
  88. - mxWindow.prototype.minimizeImage
  89. - mxWindow.prototype.normalizeImage
  90. - mxWindow.prototype.maximizeImage
  91. - mxWindow.prototype.resizeImage
  92. - mxPopupMenu.prototype.submenuImage
  93. - mxUtils.errorImage
  94. - mxConstraintHandler.prototype.pointImage
  95. The basename of the warning image (images/warning without extension) used in
  96. <mxGraph.setCellWarning> is defined in <mxGraph.warningImage>.
  97. Resources:
  98. The <mxEditor> and <mxGraph> classes add the following resources to
  99. <mxResources> at class loading time:
  100. - resources/editor*.properties
  101. - resources/graph*.properties
  102. By default, the library ships with English and German resource files.
  103. Images:
  104. Recommendations for using images. Use GIF images (256 color palette) in HTML
  105. elements (such as the toolbar and context menu), and PNG images (24 bit) for
  106. all images which appear inside the graph component.
  107. - For PNG images inside HTML elements, Internet Explorer will ignore any
  108. transparency information.
  109. - For GIF images inside the graph, Firefox on the Mac will display strange
  110. colors. Furthermore, only the first image for animated GIFs is displayed
  111. on the Mac.
  112. For faster image rendering during application runtime, images can be
  113. prefetched using the following code:
  114. (code)
  115. var image = new Image();
  116. image.src = url_to_image;
  117. (end)
  118. Deployment:
  119. The client is added to the page using the following script tag inside the
  120. head of a document:
  121. (code)
  122. <script type="text/javascript" src="js/mxClient.js"></script>
  123. (end)
  124. The deployment version of the mxClient.js file contains all required code
  125. in a single file. For deployment, the complete javascript/src directory is
  126. required.
  127. Source Code:
  128. If you are a source code customer and you wish to develop using the
  129. full source code, the commented source code is shipped in the
  130. javascript/devel/source.zip file. It contains one file for each class
  131. in mxGraph. To use the source code the source.zip file must be
  132. uncompressed and the mxClient.js URL in the HTML page must be changed
  133. to reference the uncompressed mxClient.js from the source.zip file.
  134. Compression:
  135. When using Apache2 with mod_deflate, you can use the following directive
  136. in src/js/.htaccess to speedup the loading of the JavaScript sources:
  137. (code)
  138. SetOutputFilter DEFLATE
  139. (end)
  140. Classes:
  141. There are two types of "classes" in mxGraph: classes and singletons (where
  142. only one instance exists). Singletons are mapped to global objects where the
  143. variable name equals the classname. For example mxConstants is an object with
  144. all the constants defined as object fields. Normal classes are mapped to a
  145. constructor function and a prototype which defines the instance fields and
  146. methods. For example, <mxEditor> is a function and mxEditor.prototype is the
  147. prototype for the object that the mxEditor function creates. The mx prefix is
  148. a convention that is used for all classes in the mxGraph package to avoid
  149. conflicts with other objects in the global namespace.
  150. Subclassing:
  151. For subclassing, the superclass must provide a constructor that is either
  152. parameterless or handles an invocation with no arguments. Furthermore, the
  153. special constructor field must be redefined after extending the prototype.
  154. For example, the superclass of mxEditor is <mxEventSource>. This is
  155. represented in JavaScript by first "inheriting" all fields and methods from
  156. the superclass by assigning the prototype to an instance of the superclass,
  157. eg. mxEditor.prototype = new mxEventSource() and redefining the constructor
  158. field using mxEditor.prototype.constructor = mxEditor. The latter rule is
  159. applied so that the type of an object can be retrieved via the name of it’s
  160. constructor using mxUtils.getFunctionName(obj.constructor).
  161. Constructor:
  162. For subclassing in mxGraph, the same scheme should be applied. For example,
  163. for subclassing the <mxGraph> class, first a constructor must be defined for
  164. the new class. The constructor calls the super constructor with any arguments
  165. that it may have using the call function on the mxGraph function object,
  166. passing along explitely each argument:
  167. (code)
  168. function MyGraph(container)
  169. {
  170. mxGraph.call(this, container);
  171. }
  172. (end)
  173. The prototype of MyGraph inherits from mxGraph as follows. As usual, the
  174. constructor is redefined after extending the superclass:
  175. (code)
  176. MyGraph.prototype = new mxGraph();
  177. MyGraph.prototype.constructor = MyGraph;
  178. (end)
  179. You may want to define the codec associated for the class after the above
  180. code. This code will be executed at class loading time and makes sure the
  181. same codec is used to encode instances of mxGraph and MyGraph.
  182. (code)
  183. var codec = mxCodecRegistry.getCodec(mxGraph);
  184. codec.template = new MyGraph();
  185. mxCodecRegistry.register(codec);
  186. (end)
  187. Functions:
  188. In the prototype for MyGraph, functions of mxGraph can then be extended as
  189. follows.
  190. (code)
  191. MyGraph.prototype.isCellSelectable = function(cell)
  192. {
  193. var selectable = mxGraph.prototype.isSelectable.apply(this, arguments);
  194. var geo = this.model.getGeometry(cell);
  195. return selectable && (geo == null || !geo.relative);
  196. }
  197. (end)
  198. The supercall in the first line is optional. It is done using the apply
  199. function on the isSelectable function object of the mxGraph prototype, using
  200. the special this and arguments variables as parameters. Calls to the
  201. superclass function are only possible if the function is not replaced in the
  202. superclass as follows, which is another way of “subclassing” in JavaScript.
  203. (code)
  204. mxGraph.prototype.isCellSelectable = function(cell)
  205. {
  206. var geo = this.model.getGeometry(cell);
  207. return selectable &&
  208. (geo == null ||
  209. !geo.relative);
  210. }
  211. (end)
  212. The above scheme is useful if a function definition needs to be replaced
  213. completely.
  214. In order to add new functions and fields to the subclass, the following code
  215. is used. The example below adds a new function to return the XML
  216. representation of the graph model:
  217. (code)
  218. MyGraph.prototype.getXml = function()
  219. {
  220. var enc = new mxCodec();
  221. return enc.encode(this.getModel());
  222. }
  223. (end)
  224. Variables:
  225. Likewise, a new field is declared and defined as follows.
  226. (code)
  227. MyGraph.prototype.myField = 'Hello, World!';
  228. (end)
  229. Note that the value assigned to myField is created only once, that is, all
  230. instances of MyGraph share the same value. If you require instance-specific
  231. values, then the field must be defined in the constructor instead.
  232. (code)
  233. function MyGraph(container)
  234. {
  235. mxGraph.call(this, container);
  236. this.myField = new Array();
  237. }
  238. (end)
  239. Finally, a new instance of MyGraph is created using the following code, where
  240. container is a DOM node that acts as a container for the graph view:
  241. (code)
  242. var graph = new MyGraph(container);
  243. (end)