mozdev.org

xulapp

resources:

Requirements/Design Discussion

These requirements and discussions represent a brain dump and need editing. The requirements are not closely divided into requirements and possible solutions. None are set in stone and deserve much discussion. They are divided into functional areas:

General

Items not covered by other areas:

IDE Framework

Matters relating to the IDE framework level.

Editors (General)

Matters relating to source code editors in general. Editor of one sort or another will form an important part of the XulApp environment. It is worthwhile trying to get a consistent approach rather than an ad-hoc one.

One possible framework has these components:

The editor is based on one (or more) source documents (usually xml) which act as the Model for the editor. The Editor then presents (one or more) Views of the Model to the user. The user then can edit the View directly with effect on the View only, or additionally on the structure and content of the Model.

Martijn Schrage's thesis on the Proxima editor: gathers these ideas into a coherent framework. We are in the position of having his presentation layer provided by the Firefox browser and CSS also takes care of some of the transformations between his other layers. In the Mozilla world a generalized editor framework could consist of:

  1. An XML document (or several) which serve as the model (a.k.a. the source code).
  2. An XSLT transform which transforms this model into one or more presentations. Being Turing Complete, XSLT has considerable power to rearrange, collate, and summarize the model document. This can involve the creation of new elements/attributes which are only present in the view.
  3. The browser presents the presentation view.
  4. The use of the CSS3 user-input feature permits only specified areas of the view to be editable. The CSS3 User Input specification is unlikely to be accepted, but it lives on in the equivalent -moz-user-* CSS properties. This is a powerful feature as the editor is able to keep control (and validity) of the gross structure of the document whilst allowing freeform input in other areas.. The editor must, of course, provide features for creating and transforming the gross structure which is otherwise inaccessible.
  5. The program records user keystrokes and records them into the view content at that point. (The user-input feature provides no interpretation for user input - the program must provide this).
  6. Optionally, the user input is parsed and used to update the view/model. Parsing may vary from a simple regex, to the full use of a language parser. There is a point of diminishing returns for any structured editor where imposing the structure of low level constructs become onerous for the user. For a source code editor this is probably reached at the expression level.
  7. Other user gestures (drag & drop) (cut & paste) (mouse gestures) (menu or context menu selection) etc. are used to transform the view and optionally the model.
  8. If the model has not been synchronized with the view a reverse XSLT transform may be applied to the view before the model is saved.

Editor layering and its consequences

Source documents are increasingly becoming compound documents (see xjsEditor below). An xjs document can contain xhtml documentation which can contain SVG which can contain MathML etc. It looks like document layering is a fact we will have to live with.

It also looks like we will need something akin to Microsoft OLE (Object Linking and Embedding). Editing can be either in-place or via opening a new window to edit a fragment of a document. Editors will need a framework to modify the menu, toolbar, and context menus whilst they are in control. This also implies that the use of the XUL commndset/command/keyset/key features will need to be added to the editor form dynamically. If I install a new MathML editor, I should not have to modify the xjsEditor XUL definitions to make it operate.

It will probably be a good idea to develop a set of editors in tandem so that commonalities can be identified and moved into an editing framework.

Parsing Framework

There is no getting away from the requirement for a good parser. The following requirements are a start:
  1. Context Free Grammars. This gives composability/reusability of grammar modules.
  2. CFG's also allow simpler grammars as ambiguity is not an issue.
  3. CFG Parsers don't require the degree of hand crafting that LALR(1) grammars require.
  4. Speed is nice, but: The editors need to parse single expressions or statements. OR The parser is importing some existing code into the framework, so speed is not essential. (Just as well we are not going to get it!)

This indicates that an Earely or Tomita parser should be the target. A number of each (written in C) are available in open source format.

In the interim, text can remain un parsed (or manually parsed) and the JS system can bletch about it - which is what happens now anyway.

Editors (XJS)

Observation: Javascript execution is way too slow to hold Javascript in source form and then process it in an editor. A simple tokenizer, written in Javascript, can take from five to ten seconds to process a 1000 line source file. Another approach is needed. If the Javascript is held in an XML format then scanning and parsing are handed over to the XML parser which operates ten to twenty times faster. It turns out that this offers some unique opportunities.

  1. Documentation and other items may be added to the source document.
  2. Embedded Links between documents is possible.
  3. We can add features which make editing easier (code folding, transformations etc.)
  4. We can support features of a language which has not become available yet - Javascript 2.0.
  5. This enables other feature such as type checking, code completion, syntax checking etc.
  6. We don't have to present the XML to the programmer. The "Enough pointy brackets already" crowd have a point.

The current implementation of the xjsEditor fall into this category. A simple mockup can be found here. In the current implementation, the model is transformed into the view and then retransfomed on saving. The model is not maintained during editing. This will probably have to change.

A set of templates is used to create new structure (if and else so far). The template is transformed using the XSLT model/view transform and inserted into the view (currently at no particular point). Structure transforms should also be performed using this mechanism.

Editors (XUL)

The current implementation of the xulEditor falls into the ad-hoc category and should be re-written. It currently maintains a model and several views which are synchronized during editing. This requires that a map associating the view and model elements need to be maintained. The same technique can be reused by the editor framework above.

The current editor uses widget templates to add new items to the design using Javascript code and also to identity insertion points. Recent changes to the XUL for tree, listbox and tab components require multiple changes to the target document to maintain consistency. This is also required for row and col elements to maintain a correct number of children. The use of XSLT to transform a template depending on the current document state is probably required.

This editor is also complicated by the fact that multiple input documents need to be maintained simultaneously: XUL, CSS, DTD, Javascript.

The xulapp project can be contacted through the mailing list or the member list.
Copyright © 2000-2017. All rights reserved. Terms of Use & Privacy Policy.