Suggested Improvements to Form Maker

Improvements to form-maker:

1. Make naming independent of labeling. Use HTML <label>your_favorite_label</label> for user labels, use global name attribute for user element naming. Use global ID attribute for internal naming.
Allow users to prefix the global ID and name attributes. Since HTTP POST uses the element name, the above approach allows maximum user and 10Web flexibility for element naming. This means adding the user complexity of distinguishing between a visible label (i.e. what displays in the form ) and a name used by POST to deliver field values from the client to server. However your "advanced" mechanism hides the complexity from the non-advanced user.

2. Allow all blocks to be labeled, named and ID'd; especially the custom HTML block. Internally use a custom form-maker prefix on all IDs (e.g. all IDs are prefixed with '_FM' ) and then allow users to specify any id not prefixed with the internal prefix. This allows consistent naming of the generated HTML and allows integration of custom blocks and HTML into the form maker general naming scheme.

3. Develop container blocks whose function is to contain, position and style the contained blocks (just like HTML). Allow conditional fields to select container blocks for actions. This solves many customer layout and presentation problems.

3. Improve conditional fields as follows:

Each conditional field should be structured in a more programmer friendly way:
Here is a small EBNF syntax definition of how it could work:
Note
::= means "is defined to be replaced".
--| means "end of definition".
| means alternative
* means 0 or more,
+ means 1 or more,
? means 0 or 1,
brackets [ and ] provide term grouping
Metasymbols are standalone identifiers and are replaced
Literals are quoted using PHP quoting rules.
// starts a comment
EBNF statements are of the form: metasymbol ::= meta_expression --|

conditional_fields ::= conditional* --|

// empty conditional fields means conditional fields are inactive.

conditional ::= 'if' condition 'then' action+ [ 'else' action+ ]? --|

condition ::= and_expression | or_expression --|

and_expression ::= compare_expression [ 'and' compare_expression ]* --|

or_expression ::= compare_expression [ 'or' compare_expression ]* --|

compare_expression ::= '(' condition ')' | comparison --|

comparison ::= field_identifier compare_operator field_value
| field_value compare_operator field_identifier --|

field_identifier ::= field_name | field_label | field_id --|
// field_name is either a user supplied element name or 10web generated name.
// field_label is a user defined element label prompted for in the form field definition.
// field_id is a 10web set value of the ID attribute on the form field "postable" element.

field_value ::= constant | 'checked' | 'selected' | 'empty' | afirmation | negation
| fieldselect_value --|

fieldselect_value ::= '@' field_identifier --|

// field_value is a value dependent on the field defined by the field_identifier.

constant ::= number | string --|

afirmation ::= 'yes' | 'ok' | 'yup' | 'sure' | ... --| // your favorite idiomatic yes word.

negation ::= 'no' | 'nope' | 'don\'t' | 'never' | ... --| // your favorite idiomatic no word.

action ::= display_action | update_action --|

display_action ::= display_command field_identifier --|

update_action ::= update_command field_identifier [ clause* ] --|

update_command 'replace' field_identifier 'with' field_value ] --|

command ::= 'hide' | 'show' | 'inert' | 'replace' --|

compare_operator ::= '=' | '!=' | '>' | '>=' | '==' | '<=' | '<' | 'like' | 'contains'
| 'prefix' | 'suffix' --|


--|

The above can be easily put into a form notation and makes conditional fields more compact and much easier to develop. With the ability to name blocks it makes it especially easy to manage conditional blocks in a form.

The ability to insert conditional blocks before, after and in between other conditional blocks as well as being able to group blocks so that a condition controls the actions in the block are crucial to improving the user experience.

4. DO NOT remove line breaks and spacing in the custom HTML block. The formatting of the HTML is important to a developer. Do the compacting upon "publishing" for the execution version. Always keep the display version with formatting intact.

5. On the Date block, Allow the current date to be a selectable default value.

6. The calculator function should be generalized to allowing assignment of values including strings to fields. E.g. if ( last_name != empty ) set credit_card_name to first_name . ' ' . last_name

7. Need to document how one adds drop-downs to a table of fields.

8. Conditional Fields. Each field should be movable just like in the form fields. This allows users to keep organized fields together and it allows rapid update when block enclosures of multiple actions on a single condition are supported.

9. General Advanced Capability. Form Maker should add a Word Press filter function call each time that a field is updated during a submit.  The filter should occur after the user completes entry of new data into the field.  The filter should be called with a form identifier, the field name and a field value.  The filter returns the original value; or an update value.  This value should then be validated in the normal way.