1,277
edits
Changes
m
Lensovet moved page CS/164/HW3 to Computer Science/164/HW3
<pre><nowiki>{ color: #82c753; background: #6d6d6d; text-decoration: none; padding: 0.25em 0.5em;
hover: { background: white; text-decoration: underline; };
layout: horizontal; };
*One | /one.htm
*Two | /two.htm
While this language does not provide true objects, some code reuse is possible. Existing menus can be embedded in larger ones by simply prepending all the elements with an additional '*' character (or more than one, depending on how deeply in the navigational hierarchy you are inserting the nav bar). The <tt>direction</tt> keyword effectively controls the interaction between these navigation bars and their relationship to each other. Furthermore, some "inheritance"-like features make the task easier for the web developer. For example, the <tt>direction</tt> keyword needs to be specified only on the first submenu and is automatically applied to all the sibling submenus in the hierarchy. CSS properties are inherited by child menus from their parents.
===Demo===
{|
! Code || Preview
|-
| <pre><nowiki>{ color: #82c753; background: #6d6d6d; text-decoration: none; padding: 0.35em 0.5em;
hover: { background: white; text-decoration: underline; };
layout: vertical; layout-width: 10em; }
*One | /one.htm
{ color: #84b6d5; marker: ☞ }
**Two | /two.htm
*Fun | /fun/
{ background: white; }
**Funtwooverride | /override
***Third level | /goodtimes.htm
{ background: gray; }
****Fourth | /four
*Oneback | /oneback
{ marker: dot; }
**Choo choo | /choo
***Overrides | /woo
****Gray | /gray</nowiki></pre> || [[Image:Navlang-overrides.png|thumb]]
|-
| <pre><nowiki>{ layout: horizontal; }
*About us
{ direction: below; }
**Directors | /directors
**Developers | /developers
**Users | /users
*Support
**FAQs | /faq
**Knowledge Base | /kb</nowiki></pre> || [[Image:Navlang-horizontal.png|thumb|A horizontal menu with the first menu item highlighted (moused over)]]
|-
| <pre><nowiki>{ layout: vertical; layout-width: 200px; element-style: rounded-tab; border: yellow thin solid; hover: { border: red thin solid; }; }
*Roadmap | /roadmap.html
*Projects | /projects
*Coding | /developer
{ direction: right; marker: dot; }
**Module Owners | /about/owners.html
**More modules | /owners</nowiki></pre> || [[Image:Navlang-vertical.png|thumb|A vertical menu with the third menu item highlighted (moused over)]]
|}
===Poster slides===
*[[Media:Navlang.ppt|Poster slides]]
==Decide on the implementation==
: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, generates the CSS for the level (if any), and consequently inserts it into a separate stylesheet created specifically for the purpose of the nav bar. Items are assigned classes for their level and all the levels above them. This 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).:The interpreter itself does only minimal error-checking. If errors occurred during parsing, they can be inspected via JavaScript after the parse is complete.
* 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.
==Addendum: succinct description of all language features==
The formatting declaration inside the curly braces can contain any CSS properties you desire, which will be passed and set to the nav bar items' <nowiki><a> and <span></nowiki> tags. A number of special keywords allow additional features. Namely:
*layout determines the direction of the navigation bar. choices are horizontal/vertical; horizontal default.
*hover allows you to specify CSS attributes which apply to nav bar elements only when they are hovered over (i.e. the a:hover and span:hover CSS selectors). uses exact same syntax as the "normal" formatting declaration.
*direction determines the direction of submenus (i.e. items with level > 1) relative to their parent item. valid choices are right, left, above, below, and same. The last is the default and does not create pop-out menus.
*marker specifies a marker which precedes all nav bar items. either 'none', 'dot', or any HTML entity such as <nowiki>☞</nowiki>; none default.
*layout-width specifies the width of the nav bar for vertical nav bars. default is 100% as per standard CSS.
*element-style specifies the style of the nav bar item. current either 'rounded-tab' or 'regular'; latter is default.
In general, formatting specs are inherited in much the same way as in CSS when a class name is appended to the element's class field. In particular, this means that children of any given element will inherit all of its properties unless they are manually overridden. Furthermore, the first time a level (i.e. *, **, ***, etc.) appears, its formatting declaration (including a lack of one) is made as that level's "prototype" formatting specification. All further items in the same nav bar with the same level will have the same formatting, as will their children, unless they are overridden themselves.
However, it is possible to override this prototype inheritance on a per-branch basis by specifying a different formatting spec before beginning the branch (i.e. as if declaring a prototype for the first time). Note that this override will complement the existing prototype, so any values not explicitly overridden will be inherited as usual. Such an override lasts for the duration of the branch in which it was introduced and is discarded once the branch is complete.
Consider and play with the following example to get a hands-on demo of how these concepts interact:
<pre><nowiki>{ color: #82c753; background: #6d6d6d; text-decoration: none; padding: 0.35em 0.5em;
hover: { background: white; text-decoration: underline; };
layout: vertical; layout-width: 10em; }
*One | /one.htm
{ color: #84b6d5; marker: ☞ }
**Two | /two.htm
*Fun | /fun/
{ background: white; }
**Funtwooverride | /override
***Third level | /goodtimes.htm
{ background: gray; }
****Fourth | /four
*Oneback | /oneback
{ marker: dot; }
**Choo choo | /choo
***Overrides | /woo
****Gray | /gray
</nowiki></pre>