Scripting Dynamic SVG
Now you're ready to do the scripting work. The SVG plugin uses a built-in (for portability) JavaScript engine, rather than the browser's engine, and it doesn't include any debugging help. If you have tough debugging problems and all else fails, cut-and-paste your scripts into an HTML page (it's all ECMAScript, after all) and let your normal debugging environment look for syntax problems. Other possible solutions are to fall back on the alert() function to help you find errors, or to fully script the plugin's contents from the HTML page via the document.embeds function. If you do that, make sure your code is portable across IE and Netscape. You'll also need to restart the browser if undiscovered bugs confuse the plugin.

Listing 3 (accounts.svg) shows all the required script in place.

Here's a rundown of the noteworthy features used.

• For neatness, a state variable holds the current set of plugin-global JavaScript variables, and records the progress of the current user gesture.
• The SVG diagram is not quite a clean slate—you don't want the user to draw messy lines just anywhere. The terminals array specifies the anchor positions for the start and end points of lines. These anchor points are related to the positions of other graphical elements on the page.
• When the user draws a line, one end of the line will be always be near the cursor. However, if it's too near, the browser generates a large number of extra, messy events when the cursor occasionally passes over the line end, and your state diagram will be badly messed up. You need a simple adjustment to keep the line end away from the cursor a bit, or stop it from receiving events. The function extendDraw() shows one solution.
• When users begin drawing a line, you highlight the object they've clicked. Users can't live on faith alone, so every change in state should return a visual cue. The function putBorder() contains an example.
• To change the <line> tag itself, you can cheat, as done here, and modify the tag's x2 and y2 attributes directly. Changing the endpoints is an Adobe-specific feature that is not supported in the SVG standard; but it's so much easier than destroying and recreating the entire SVGLineElement object for each change, that in my opinion, a useful SVG implementation must support this extension. The renderLine() function in the sample code illustrates how to change the line endpoints.
• Finally, you can (and should) store your data in <text> elements instead of in JavaScript variables. This is a little more work but provides two conveniences. First, if the element is visible on screen, you can watch its contents update dynamically as you change the value. Second, saving the data in <text> variables makes it easy to access from outside the SVG plugin environment. Finally, because the plugin has a separate scripting environment than HTML, it can be tricky and frustrating to extract JavaScript variables from the plugin directly. The results are not consistent at this stage in the plugin's evolution. Right now, you're better off storing data in SVGTextElement objects than in variables. However, the problem should disappear as the product matures.

Capturing user input

Shopping for Technology

Shopping for Technology	Setting Up the User Interface
Capturing user input	Scripting Dynamic SVG