 From dfraser+page@capybara.org  Wed Apr  5 13:47:03 2000
Return-Path: <dfraser+page@capybara.org>
Received: from mail.lweb.net (root@mail.lweb.net [209.205.45.34])
	by beorn.capybara.org (8.10.0/8.10.0) with ESMTP id e35Hl3O12960
	for <dfraser@capybara.org>; Wed, 5 Apr 2000 13:47:03 -0400 (EDT)
Received: from [209.205.45.168] (pm01-168.lweb.net [209.205.45.168])
	by mail.lweb.net (8.9.3/8.9.3) with SMTP id NAA16112
	for <dfraser@capybara.org>; Wed, 5 Apr 2000 13:54:23 -0400 (EDT)
Message-Id: <200004051754.NAA16112@mail.lweb.net>
From: Dan Fraser <dfraser+page@capybara.org>
To: dfraser@capybara.org
Subject: cs470 stuff: menu options and adapter
Date: Wed,  5 Apr 2000 12:47:18 -0500
X-Mailer: EPOC32 Email Version 1.50
Status: RO
Content-Length: 2791
Lines: 50

Adding Menu Options

Hardware and Software requirements:

Independent -- XML code.

System Architecture Description:

Mozilla uses an XML-based language for its graphical user interfacec 
specification.  This language specifies the various graphical objects in the 
interface, their attributes, and their reationships.  The language also allows 
a JavaScript function call to be associated with different aspects of a GUI 
element.

Program Design Description:

To add the "File -> Save (with images)..." option to the Mozilla menu systems, 
we first needed to locate the XML language files (XUL) which specify the menu 
bars in the editor and in the main browser window.  After consulting the XUL
documentation on the mozilla.org web site, we were able to make modifications 
to these files and have those modifications appear in the browser.  From 
there, it was a small step to add the new option we required. 

We then had to locate the flles containing the JavaScript functions which are 
called from the Mozilla interface, and add our own function there, which would 
eventually hold our new image saving functionality.

Souce Code Listing;

in file mozilla/xpfe/browser/resources/content/navigatorOverlay.xul:
<menuitem id="menu_close"/>
<menuitem id="context-savepage" value="&savePageCmd.label;" accesskey="&savePageCmd.accesskey;" oncommand="savePage();"/>
<menuitem value="Save page (with images)..." oncommand="fancySavePage();"/>
<menuseparator/>
<menuitem accesskey="&sendPageCmd.label;" observes="Browser:SendPage"/>
<menuitem accesskey="&editPageCmd.label;" observes="Browser:EditPage" />
<menuseparator />

Test plans: 

Try the menu item.  If it works, testing is compelete.

Validation report:

Testing was completed successfully.

Guide for further system maintenance:

The Mozilla XUL Introduction:
http://www3.sympatico.ca/ndeakin/mozilla/xultu/


--------------

Adapter Documentation

Hardware and Software requirements:

Architecture independent except actual file saving functionality which
has not yet been designed.

Software Architecture Description:

An unexpectedly difficult task in our project turned out to be saving our 
modified document to disk.  Mozilla has several existing functions to perform 
this task, but they are all considered to be legacy code and none of them are 
completely integrated into the main browser's code base -- they only exist in 
the editor, or as non-scriptable classes in the main browser.

Program Design Description:

Since we needed to perform this task from the new JavaScript-controlled user 
interface, it was necessary to have "scriptable" code to save our modified 
document to disk.  In order to make this possible, we chose to use the Adapter 
design pattern studied in CS471.  We located the legacy code which converts a 
document to HTML (nsDocumentEncoder), and began to create a new class and 
JavaScript interface (similar to the JavaScript Debugger group) which contains 
and uses an nsDocumentEncoder object.  We called this class 
nsScriptableDocumentEncoder. 

There were two major difficulties involved in making this strategy work.  
First, due to the XPConnect interface beween JavaScript and C++, we were very 
limited in which data types we could pass into our new methods, and we could 
not find any up-to-date documentation on this interface.  With help from 
Netscape employees on IRC, we believe we have developed a workable inteface 
and corresponding IDL file.

The second difficulty is creating an instance of our object somewhere
within the Mozilla code, and actually getting JavaScript messsgaes
sent to that object.  This involves making modifications to the
nsDocument class, creating a Factory, and actually calling our constructor.

Test plans:

None developed.

Guide for further maintenance:

Due to our time constraints and the complexity of the task, we were 
unable to implement the required Factory methods and completely compile and 
test this code.  Hopefully another member of the Mozilla community will 
continue this work where we left off.

See the web pages created by other Mozilla One group members for more
details on further maintenance in this part of Mozilla.


