Pushing Forms and form fields in Flash

Posted on April 9, 2009

0


[This is a definition page]

0: Design goals and strategy

A “designer” with basic knowledge of HTML and forms should be able to create working forms. The main idea is: By creating form definitions in XML you can produce and modify working database driven forms with insane speed. Second: when the XML deals with positioning of all elements, pixel perfect results are easier to produce and modif than via the flash-IDE.

With the strategy as defined in the framework, it is possible to define all forms via drag and drop in an visual editor: that outputs the form XML, closing the gap between Interaction design and the end-result. Pixel-perfection (the exact positioning of elements) can be achieved by using a visual design made by the graphic designer as the template for the visual.

Data connections and exact XML templates to bind data to and from the server can be inserted later in the design process, as well as rules for layout and behaviors.

A conceptual version for this Framework was built for a mini-site for Cadillac in 2008 and will be revised in 2009.

0.A: Basis

  1. Declaritive
  2. No programming required to build forms
  3. No programming required to connect forms to the database and post / parse data
  4. Basic behavior of objects are covered in rules

0.B: Shape

  1. Forms are defined in separate XML files, making the total application scalable.
  2. The syntax of the XML is pseudo-HTML. Forms and form fields use the same tag names and basic definition to make programming easy
  3. Push: Form fields can be dynamically created using the XML definition (push)
  4. Passive Mapping: Form fields are placed on the Flash stage. The fields themselves are passive. When the form-XML is loaded, this engine maps the form and object definitions to the existing objects on stage.
  5. Active Mapping:  [Will not be implemented] Each form field on stage actively calls out to the XML definitions and read it’s specific rules and definitions.

0.C: Approach 1: Using pull from Flash – building forms and structures in Flash, calling XML from stage

  1. Each form in Flash is of class “Form”.
  2. Each form exists on stage in Flash.
  3. Each form on stage in Flash has an unique ID that corresponds to the file-name of a form-definition attached to that form.
  4. The form loads the XML and the Form class maps each item-definition (and behavior) in the XML to the corresponding item in the Flash form.
  5. Form fields and objects (lists, buttons) can be placed on stage and HAVE to have the exact same name as the corresponding form objects in the XML definition.

0.D: Approach 2: Using push from XML, pull from Flash – building forms in Flash, calling them from XML

  1. Each form in Flash is of class “Form”.
  2. Each form exists only in the Library of that flash movie.
  3. A separate XML defines the application structure.
  4. The forms are called bij the XML and pulled from the library
  5. When the form comes to existence, it calls for it’s XML definition and parses this to set the rules.

1: Basics Patterns

Most forms follow a very basic pattern:

  1. Created to allow users to interact with any back end / database / data storage via input of data.
  2. Input is either: text, numeric, from a (select) list, or boolean (true/false, yes/no).
  3. Data is either visible or hidden (i.e. stuff that is relevant for the database, but not for the user: like the User ID).
  4. Basic actions are: “Submit data” and “Cancel”.

1.A: User input

  1. The user can submit data or cancel the action.
  2. Input can consist of text, numbers, a selection from a list, the upload of a file.

1.B: Client side verification and feedback

  1. Input of a specific type (i.e. e-mails, numbers) has to apply to specific rules, to pass the verification.
  2. Feedback to the user (on invalid input and Server side feedback) is shown either in the form or in a popup.

1.C: Interactions with the backend

  1. Existing data is loaded from the database and presented in the form.
  2. Template-data (like data in select lists) is loaded from the server and presented in the form.
  3. Inserted and modified data is sent to the server, verified by the server side business logic and stored in the database.
  4. Server side Errors (either “soft errors” from verification or “hard errors” like server side failures) are returned reported to the Flash client and presented to the user .

2: XML definitions

Instead of creating “intelligent forms” and “intelligent form objects”, fields and form objects (buttons, fields, lists)  at client side are “dumb”. Behaviors per field and form are defined in generic classes and linked to objects via XML.In other words: the XML contains all intelligence.

Basic pattern:

  1. Forms and form fields are dumb.
  2. There are generic classes dealing with data verification, data connections, data exchange with the server and feedback to the user.
  3. Using XML definitions forms and form objects (buttons, fields, lists) are connected to item-specific behaviors and data-sources.

2.A: Client side Rules

  1. Are defined in generic classes.
  2. Are linked to forms and form-objects (buttons, fields, lists).
  3. Are specified in the form XML

2.B: Data Connections (basic version)

  1. Data exchange with the database are done via POST and GET calls.
  2. The form-XML contains the link to the specific server side script AND the XML-template used to send data.
  3. Mapping from the form to the XML template is done in the Form-class.
  4. Data connections are dealt with server side.
  5. The return set from the server is XML.
Advertisements
Tagged: ,
Posted in: FrameWork