There are many possible directions for improving jsLib. Some of the more important improvements are best addressed by refactoring first, then adding new functionality. The benefit of refactoring is that it allows you to test changes using existing tests.
I do not expect that all of the tasks will be completed. Do as much as you can. Also, if you have other ideas for improvement we can discuss them in class.
It is desirable to be able to divide the content area into multiple panes. For example, a non-leaf section could use the top pane to place content (say an image) that is displayed regardless of the menu item that is selected in the non-leaf section's submenu. The submenu selections the determine content to be placed in the bottom pane.
Supporting subdivided content requires a refactoring of both menus and layout. Then menus can keep track of their own content panes rather than always using the global Layout current pane.
The "put" methods in the Layout object need to be made available for all pane objects, not just the current pane. Rather than using an educator object for panes, the should be created with a constructor, with methods added to the constructor prototype.
Sometimes content can be generated dynamically. For example, part of the jsLib documentation can be generated by extracting content from comments in the JavaScript files. To support this SectionU, MenuU, LeafMenuItemU, and NonleafMenuItemU all need create() methods similar to the create() method of DefaultMenuItemU. Other methods may be needed such as a method to add menu items to a menu or to add a menu to a section.
For some of the JavaScript files in jsLib, the only explanation for why they contain the objects and classes that they contain is "they just grew that way". I encourage you to reorganize the file contents in a more sensible fashion as long as you make the appropriate changes in the JavaScript file inclusions in the documentation and test web pages. You may need to take some care with the order of the inclusions.
A <object> tag or an HTMLObjectElement is the only way to get an applet into a web page that works with all browsers. It is desirable to have some support that makes it easier for a web designer to specify the applet. More information about this will be made available upon request.
Browsers consider XMLHttpRequest loads to be a security violation if the load is from a different server. However they handle the violation in different ways, making it difficult to put up a useful error indication.
This problem could be addressed by checking urls before attempting a load. If the schema or authority component disagrees with the schema or authority of URL.getDocumentURL() then an error page can be generated. This error page can give a description of the problem that is independent of the browser.
I have done minimal debugging of the problems encountered with Internet Explorer v.8. Correcting the problems is probably too ambitious for the course project but it would be useful to have a listing of the types of errors encountered on various tests.