Visual Page Editor - Data Binding

There are two possible directions to take for the application builder's form editor.

• Take a ZRM model file and generate a form with the appropriate input fields (bottom up)
  • The user should be able to define and view the Schema (JSON Schema under the covers) (manually or in the case of some datastores automatically). A property sheet should optionally be able to be added to the DataStore's for edit/display of schema information associated with a datastore. If the schema is manually provided, a url should be provided with the location of the schema.
  • The user needs to be able to browse the schema fields for a given datastore instance on the Data Pallette for datastores which support optional schema feature. Expanding the datastore instance in the pallete should display the field names (and associated types as icon) under the datastore (preferably with sample data values).
  • The user should be able to drag schema fields from the data pallette onto the page surface, to create a data-bound widget for that field. There will be multiple widget mapping options possible for field types, so a widget to type mapping registry is needed client-side within the tool. When the user drops the field on the canvas, a menu to select the widgets for that field's type should be displayed. The HTML widget widget should be added into the page (similar to adding from Create wdget pallete), with additional dojox.wire databinding which connects the value of the widget to the value of the data field in the datastore.
  • The user should be able to view the databinding of any value (form widget) defined in an html page. User should be able to open Properties page for a widget and see a Data tab (similar to the more complex data binding tabs of Grid and Combobox) to see the datastore and field that the widget is bound to. For single valued widgets an underlying dojox.wire instance should be created/managed by the tool when the widget has databinding.
  • A higher level Form wizard should be provided to assist the user with building HTML forms faster. The user should be able to drag a DataForm widget from the Create widget pallete onto the canvas (creating underlying html
    tag with a custom DataForm widget type (extending dojo's Form widget capabilities). The user can drag and drop a schema "Type" from the data pallete onto the DataForm, and the form should automatically populate itself with data-bound HTML widgets using the default field type to widget mapping for each field in the Type. The result of the dnd of Type to DataForm should be that the html form has and html child form widgets declared in the source code of the page.
  • When a user opens the property sheet for a DataForm, the Data tab of the form should work similar to other complex data-bound widgets (eg. Grid). The datastore instance that the DataForm is bound to should be changable, and the fields from the datastore's schema (mapped to child form field widgets) should be displayed (very similar to how you define fields to columns in the Grid widget). This table of field/formwidget bindings must reflect the data-bound child widgets of the DataForm. It should also deal with mapping of regexp and other contraints between the widgets and the schema. Checking/unchecking fields/widget mappings from the table should remove the associated field from the DataForm html markup.
  • For complex data-bound widgets like DataForm or Grid, the schema definition is optional. On the Data property sheet of these widgets, the widget must still allow adding fields in lieu of having a schema specified.
  • For individual form widget fields, the Data tab needs to be added to the property sheets so that dojox.wire databindings can be added/removed/modified for the widget's value to datafield mapping.
  • Most form fields will also have label text associated with the field, and the tool should provide a custom Label property tab for specifying/defining the label associated with the form field (resulting in an underlying peer tab referencing the form widget.
  • The layout alignment functions and general multi-select (which have not yet been added to page editor) should make it easy to layout and align label/field pairs within a form; however, it would be nice to have DataForm be able to change the position/layout of all of it's child fields as a style option at the form level.
• User creates a form and the application builder generates the ZRM model file. (top down)
  • As mentioned above, for complex data-bound widgets like DataForm or Grid, the schema definition is optional. On the Data property sheet of these widgets, the widget must still allow adding fields in lieu of having a schema specified.
  • If no schema has been specified on the Data tab of the custom widget, and the user has just defined the columns/form field widgets, we should provide a button on this page that allows a JSON schema to be created, based on the field names and the most appropriate datatypes for those data fields in the schema (using the data type/widget mapping described above). The user should be able to specify the name and location where the generated JSON Schema file will be stored in the application (with a default location provided by the tool). The tool should set this as the schema url of the datastore associated with the form (if one has been specified and the datastore supports the Schema feature).