• Tuesday December 1st 2009
• Do you want fries with that project?

Skip to Content

xulapp

resources:	Home Mailing List Installation Source Code Members Screenshots

Form Designer

For reference here is the screen shot of the original designer.

The new designer will be a separately  installed FF extension.

The designer windows will be organized as in the prototype:

1. The Designer   window with widget tree and toolbar. (Top left in screen shot) A single instance will remain open whilst any Form Views are still open.
2. The Form View window. (Top right in screen shot). Multiple Form Views may be opened.
3. Toolbox (center right in screen shot). 
4. Property Inspector (lower left in screen shot).
5. CSS Style Inspector?  (I am tending towards a separate tool which can be used indepently of the Form Designer)
6. Additional forms may appear as needed (e.g wizards for building content, hooking up events to  code etc.)

Functionality:

• When the last Form View is closed the Designer closes.
• When the Designer is requested to close, any Form Views with modified content will prompt the user to save that content. The user my opt to cancel the close operation.
• The Toolbox 's visibility is toggled by the corresponding Designer toolbar icon.
• The Property Inspector's visibility is toggled by the corresponding Designer toolbar icon.
• The Style Inspector's visibility is toggled by the corresponding Designer toolbar item.
• When a Form View gains focus the Designer widget tree, Property Inspector, and Style Inspector content is switched to reflect the active view.
• Widgets can be dragged from the Toolbox onto the Designer widget tree.
• Widgets can be dragged from  the Toolbox directly onto a Form View
• Widgets can only be dropped where they are permitted by XUL syntax.
• Widgets can be dragged/copied between Form Views.
• When a  widget is placed on a design it uses context to determine what should be inserted. Currently dropping a tree in a box results in a full set of tree tags. Dropping the same widget on an existing tree may just generate an extra row or column tags (depending on drop location). This is designed to reduced the number of widgets in the Toolbox and to make them more user instinctive to users.
• The Designer widget tree supports internal drag & drop editing and cut & paste editing. 
• When a widget is dropped in the old design an elaborate system of templates was used to determine the inserted content. Some recent widget changes such a tabbox and listbox invalidate the single insertion site assumption made by that system. A new system of widget templates will be based on XSLT transforms stored in a similar manner to the current widgets.xml file. Using XSLT, content may be injected in multiple target sites and can be applied more intelligently. . e.g. Adding a column to a grid would add the column and also the corresponding row tags, so that the grid remains syntactically valid.
• A new design time widget will be created to act as a placeholder for generated content whose details are not fully known. With a distinctive appearance this widget will guide the use in inserting correct content for the particular location.
• A second, optional, toolbar will be added to the Designer (or possibly the Property Inspector). These items will operate on the currently selected widget(s) and offer fast path property changes. The following :are examples:
• toggle orientation vertical/horizontal.
• increment/decrement flex, set to zero.
• pack etc..
• Add an id to a widget. The Designer should allow direct editing of the id value.
• It should be possible to lock a design so that widgets/properties may not be inadvertently altered.
• The Designer must support undo/redo. Separate undo lists will be maintained for each Form View.
• Optionally, the editor can store DTD constants for constant strings used by widgets. (Labels, keys etc.) The old system has a prototype version of this but it is hampered by loss of DTD entity keys during xml loading. This also requires that all widgets have an id. 
• If all widgets are to have id's then a system is required of assigning a leading underscore to the id's of widgets which are to not  accessed from JS. This will enable the xalib/.../Content.js  not to load the controls map for those widgets.
• Form Designer must have a way to create text nodes for widgets such as <description>. Perhaps this can be a pseudo widget on  the Toolbox.
• A means to hook-up events to JS code is required. (Needs and editor)