1,277
edits
Changes
→Decide on the implementation: interpreter details
:We considered both an AST and objects for the interpreter's internal representation of the input. In the end, we decided that objects are better suited to the data. Although navigation bars are hierarchical, and hence seem to lend themselves to ASTs, the hierarchy is not explicit in the syntax. While this makes the input files much easier to modify and extend, it also makes it difficult for the parser to create an explicit tree from the syntax. Hence, we process the input lines as individual objects, and allow the interpreter to deal with the implicit tree structure.
* interpreter/compiler:
:The interpretation is fairly straightforward; the interpreter goes through the object representation of the input, generating the appropriate CSS and HTML as it goes. The interpreter keeps track of the current item's location in the hierarchy to place it at the proper level of the navigation tree. The interpreter generates unique class identifiers for the levels as it encounters them, and consequently allows inheritance to take place entirely using CSS's own inheritance mechanisms. Individual submenu overrides, consequently, are also entirely handled by CSS as far as inheritance is concerned (i.e. an override inherits from the prototypes of its level and all the levels above it and then overrides/adds additional formatting of its own that affects it and its direct children & siblings).
* debugging:
:Our distribution is packaged with an HTML page with a text box. You can type an input program into the text box, and the output navigation bar is displayed below. If there is an error, the error message is displayed instead of the navigation bar.