|
|
(4 intermediate revisions by 2 users not shown) |
Line 1: |
Line 1: |
− | ==[http://www.cs.umd.edu/%7Emeesh/cmsc420/spr07/part1/p11/node20.html Using the provided XML processing code to get a working parser]==
| |
− | === Node -> Element ===
| |
− | <blockquote>
| |
− | In the DOM, every XML object implements the org.w3c.dom.Node interface. Nodes have a lot of useful methods, but the ones you care most about are getNodeName(), getNodeValue(), and getAttribute(). Suppose you had a Node object representing one of our command elements. You could determine which command it was with the following code:
| |
− | <code><pre>
| |
− | Node command = ...;
| |
− | if (command.getNodeName().equals("createCity"))
| |
− | // createCity command
| |
− | </pre></code>
| |
− | To get the value of an attribute, you could use this code:
| |
− | <code><pre>
| |
− | String name = command.getAttribute("name");
| |
− | </pre></code>
| |
− | </blockquote>
| |
− | If you read the Java API, you'll see both Document and Element are subtypes of Node. A Node does not have the method getAttribute(). But Element does have a getAttribute() method.
| |
| | | |
− | === Node Child List ===
| |
− | <blockquote>
| |
− | To ignore comment nodes, you can even do an instanceof check of the command node to make sure it is of type Element.
| |
− | </blockquote>
| |
− | instanceof checks can be costly. If there's an alternative, you should use it. That said, Node has a method called [http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#getNodeType() getNodeType()].
| |
− |
| |
− |
| |
− | == [http://www.cs.umd.edu/~meesh/cmsc420/spr07/part1/p11/node21.html Outputting XML using DOM] ==
| |
− |
| |
− | === appendNode -> appendChild() ===
| |
− | <blockquote>
| |
− | To append an Element to another Node:
| |
− | <code><pre>
| |
− | results.appendNode(elt);
| |
− | </pre></code>
| |
− | </blockquote>
| |
− | This should be
| |
− | <code><pre>results.appendChild(elt);</pre></code>
| |
− | Read the API.
| |
− | == [http://www.cs.umd.edu/%7Emeesh/cmsc420/spr07/part1/p11/node22.html Outputting XML Conventions] ==
| |
− |
| |
− | === Error tag typo ===
| |
− | <blockquote>
| |
− | General <error> Output
| |
− |
| |
− | This is the form (in the exact output order) of a general <error> tag. The <parameters> tag will always be present even if there are no parameters to the command. In each command there may be several errors listed if several errors occur in a command you will only output the error of highest priority. For more information see XML Input specification for each command.
| |
− | <code><pre>
| |
− | <error type="error1">
| |
− | <command name="name1"/>
| |
− | <parameters>
| |
− | <param1 value="value1"/>
| |
− | <param2 value="value2"/>
| |
− | </parameters>
| |
− | <error/>
| |
− | </pre></code>
| |
− | </blockquote>
| |
− | The last tag should be </error>, not <error/>.
| |
− |
| |
− | === Printing to System.out ===
| |
− | <blockquote>
| |
− | It is sufficient to merely spit these out to System.out (the standard output stream) as they are discovered when processing the commands. However, remember that the result must be a well-formed XML document and a well-formed XML document must have a single root element.
| |
− | </blockquote>
| |
− | Do not call System.out.println() to print out your output. Instead, create a new Document and append Elements to it as you process commands. You can print a Document to System.out using XmlUtility.print().
| |
− |
| |
− | === Output schema? ===
| |
− | <blockquote>
| |
− | (You may want also to stick an <?xml version="1.0" ?> tag in the front (JAXP XML outputters will usually insert it in for you). So in other words, you don't need to worry about building a DOM object, since we'll expect you to just print it to the standard out anyway. We will test your output XML by feeding it into our XML parser, validating it against our schema, and then reprinting the DOM object we create, and diffing the results. After we standardize your output by building it into a DOM object and rewriting it to a stream, our XML and your XML should look exactly the same.
| |
− | </blockquote>
| |
− | We do not have an output schema. Make sure that your output matches the spec requirements.
| |
− |
| |
− | == [http://www.cs.umd.edu/%7Emeesh/cmsc420/spr07/part1/p11/node24.html Drawing a spatial map using CanvasPlus] ==
| |
− | === Color class ===
| |
− | It should be noted that all colors used in CanvasPlus refer to their java.awt.Color counterparts.
| |
− |
| |
− | == [http://www.cs.umd.edu/%7Emeesh/cmsc420/spr07/part1/p11/node26.html Input] ==
| |
− | === spatialWidth and spatialHeight ===
| |
− | <blockquote>
| |
− | The attributes are spatialWidth and spatialHeight, both Unrestricted Integers...
| |
− | </blockquote>
| |
− | spatialWidth and spatialHeight will always be 2<sup>k</sup> by 2<sup>k</sup>. That way you can take advantage of bit operators.
| |
− |
| |
− | === List cities ===
| |
− | <blockquote>
| |
− | listCities
| |
− | Prints all cities (vertices) currently present in the graph.
| |
− | </blockquote>
| |
− | Graph here means data dictionary.
| |
− |
| |
− | === Nearest City tie ===
| |
− | <blockquote>
| |
− | nearestCity
| |
− | Will return the name and location of the closest city to the specified point in space. To do this correctly, you may want to use the PriorityQueue-otherwise, you might not be fast enough.
| |
− | </blockquote>
| |
− | If there is a distance tie, check the city names using java.lang.String.compareTo() (for a distance tie, the nearestCity name is less than the other city name).
| |
− |
| |
− | == JAR file ==
| |
− | InclusiveIntersectionVerifier.intersects(Line2D seg, Rectangle2D rect) does not work properly. This shouldn't be an issue for part 1. A corrected JAR file will be made available for parts 2 and 3.
| |