public interface DevTools
This includes interfaces such as:
Dashboards & Tools provides a pattern for end user creation and configuration of UI components which enables the framework to store and re-create components exactly as the user configured them.
Unlike simple serialization, Dashboards & Tools is designed to capture only UI state created directly by end user actions, and not transient or derived state (for more on this behavior and how it is different from serialization, see "Stored vs Derived State" below).
  To achieve this, user-editable components are created via a special pattern (not just the
  usual 
  
  new SomeComponent()),
  and changes to user-editable components that are meant to be saved are likewise applied via
  special APIs (not just direct calls to someComponent.setSomething()).
  
The main components and behaviors involved in Dashboards & Tools are covered in brief below - each of these points is covered in more detail in further sections:
Palettes.  Palettes
 create components from PaletteNodes, which are
 data records
       containing the component's class and default settings.  Some Palettes
       provide an end user UI for creating components (eg drag a node from a Tree).
  Palette is represented by an
 EditNode, which tracks the created component along with the
 data necessary
       to save and re-create the component.
 EditContext manages a list or Tree of EditNodes,
 and provides
       APIs for serializing and restoring EditNodes to and from XML and JSON, and
       updating the nodes as users make changes.
 "edit mode"
 behaviors.  When "edit
       mode" is enabled, when an end user interacts with the component, the component will
 save changes to its EditNode or to child EditNodes in the
 EditContext.  For example, PortalLayout can track and persist changes to
       the placement and size of portlets made by end users.  EditMode behaviors
 are implemented by EditProxies, and different edit
 mode behaviors can
       be turned on and off for different kinds of tools.
  
Palettes showing components that the user can create
 Palette to create them.  The
       editing area is just an ordinary UI component that has been placed into "edit mode"
       and provided with an EditContext.  Depending on the type of tool, the main
 editing area might be a DrawPane (for diagrams), a
 DynamicForm (for a
       form builder) or various other widgets.
  built-in UI for
       selecting one or more of the components being edited.
 EditContext.getSelectedEditNode() provides the current edit node, and
 EditContext.setNodeProperties()
 lets you manipulate its persisted state.
  EditContext to 
 obtain XML or JSON Strings
 representing the
       data to be saved, as well as to 
 restore saved state from
 such Strings.
       DataSources can be used to store whatever is being edited: the serialized form is just
 an XML or JSON String, so it can be stored as an ordinary DataSourceField value. 
  
Palettes
 User-editable components are created by Palettes. 
 Palettes
 create components from PaletteNodes, which are
 data records
  containing the component's class and default settings.
  
  Most types of palettes provide a UI for an end user to create components from
 paletteNodes.  For example, a TreePalette
 presents a hierarchical
  set of paletteNodes as a tree, and allows end users to drag nodes out in order
  to create components.  All palettes also support
 programmatic creation of components from
  paletteNodes.
  
  paletteNodes can be programmatically provided to a Palette, or, 
  Palettes that are derived from
 DataBoundComponents can load
 paletteNodes from a
  DataSource.
  
 When a component is created from a paletteNode, an EditNode is created
 that tracks the live component and the
 state needed to re-create
  it, called the defaults.  
  
 An EditContext manages a Tree of EditNodes,
 and provides APIs for
  serializing and restoring EditNodes and updating the tree of nodes.
  
  When an EditNode is added to an EditContext, typically it is immediately placed
 into "Edit Mode" (see EditContext.autoEditNewNodes for how
  this can be controlled).  In Edit Mode, components introduce special behaviors, such as the
 ability to directly edit the titles of Tabs in a TabSet by double-clicking, or
 support for dragging new FormItems into a
 DynamicForm.  Changes made while a
 component is in Edit Mode are saved to the component's EditNode, in
  EditNode.defaults. 
  
 Each component that has editMode features has a corresponding EditProxy
  that implements those features.  A component's EditProxy is automatically
 created when a component goes into edit
 mode, and overrides the
  normal behavior of the component.  By configuring the EditProxy for a
  component, you configure what behaviors the component will have when in edit mode, and which
  specific actions on the component will cause changes to be saved to its EditNode.
  
  For example, CanvasEditProxy has features for 
 saving coordinates as child
 widgets are dragged, and
  GridEditProxy has features for persisting 
 field visibility when
 end users show and hide
  fields.
  
 
  You can configure which EditProxy behaviors are active via
 PaletteNode.editProxyProperties and EditNode.editProxyProperties, and
 via the
  editProxy AutoChild.
  
  The EditContext has the capability to manage a Tree of
  EditNodes in order to enable tools that create a hierarchy of Smart GWT
 components.  When you use EditContext.addNode() and add a new EditNode underneath
  another EditNode, the EditContext will automatically try to determine how the parent and
  child are related and actually call APIs on the widgets to establish a relationship, such as
  a Tab being added to a TabSet, or a FormItem being added to a DynamicForm.  The
  EditContext uses the same approach as is used for Reify Drag and Drop - see
  Reify overview for details.
  
  
  Note that many if not most kinds of tools use only a flat list of EditNodes - for example,
  in a collage editor, photos may sometimes be stacked on top of each other, but a
 parent/child relationship in the sense of Canvas.children is not established by doing
 so.  Likewise, although the Mockup
 Editor sample allows end
  users to create mockups using Smart GWT components, the components never truly become
  children of other components.  Instead, as is typical of most mockup tools, hierarchy is
  achieved visually by simply placing a component on top of another and within its bounding
  rectangle.  
  
  Most types of tools use a flat list of EditNodes - generally speaking you will
  only use the hierarchy management features of Editcontext if you are creating a
  tool that actually allows end users to build functioning Smart GWT screens, such as the
 Form
 Builder example.  For such applications, use 
 EditContext.allowNestedDrops
 to enable drag and drop interactions that will allow end
  users to place components inside of other components.
  
  The purpose of having an EditNode for each UI component is to maintain a
  distinction between the current state of the live UI component and the state that should
  be saved.  For example:
  
EditContext.setNodeProperties() by application code
  
setCanvasDefaults()
  method (PaletteNode also has equivalent setFormItemDefaults() and 
  setDrawItemDefaults() methods).
  
  Sometimes, however, your code does not directly create the PaletteNode itself.  For
  example, when you provide TileRecords that will be
  used in a TilePalette, you provide the PaletteNode 
  defaults on the TileRecords, but your code does not actually create the PaletteNodes.  In 
  this case, you create a properties object as described above, and then you call its 
  getPaletteDefaults()
  method to obtain a Map of properties suitable for specifying PaletteNode defaults.  This 
 code, taken from the Collage Editor sample, demonstrates 
  the approach:
      Img img = new Img();
      img.setTitle(title);
      img.setSrc("stockPhotos/" + photos.get(i));
      TileRecord record = new TileRecord();
      record.setAttribute("title", title);
      record.setAttribute("type", "Img");
      record.setAttribute("defaults", img.getPaletteDefaults());
  
  Optional Module 
  for this framework.
  Any tools that work with hierarchies of system components or derivations of them will also need the system schema which can be loaded by either of the following:
JSP tag:
<script><isomorphic:loadSystemSchema /></script>
HTML tag:
<SCRIPT SRC="../isomorphic/DataSourceLoader?dataSource=$systemSchema"></SCRIPT>
EditContext, 
SerializationSettings, 
Palette, 
HiddenPalette, 
TreePalette, 
ListPalette, 
TilePalette, 
MenuPalette, 
EditPane, 
EditTree, 
EditProxy, 
CanvasEditProxy, 
LayoutEditProxy, 
SplitPaneEditProxy, 
TabSetEditProxy, 
StatefulCanvasEditProxy, 
ImgEditProxy, 
LabelEditProxy, 
ProgressbarEditProxy, 
WindowEditProxy, 
DetailViewerEditProxy, 
MenuEditProxy, 
SectionStackEditProxy, 
SectionStackSectionEditProxy, 
FormEditProxy, 
FormItemEditProxy, 
FileItemEditProxy, 
TextItemEditProxy, 
TextAreaItemEditProxy, 
SelectItemEditProxy, 
CheckboxItemEditProxy, 
DateItemEditProxy, 
GridEditProxy, 
DrawPaneEditProxy, 
DrawItemEditProxy, 
DrawLabelEditProxy, 
FacetChartEditProxy, 
com.smartgwt.client.tools.EditContext#editNodePasteOffset, 
EditContext.getRootComponent(), 
Palette.getGenerateNames(), 
TreePalette.getComponentDefaults(), 
EditPane.getRootComponent(), 
EditTree.getRootComponent()