Semantic Forms Rules

From IdeaWiki

Jump to: navigation, search
Type Improved form functionality
Implementation New extension ()
Prerequisite
Origin
Current State Under discussion
Owner

Contents

General Description

Currently dynamic behavior of Semantic Forms is achieved by adding additional parameters to inputs (or by having dedicated inputs). This is a good approach where the dynamic behavior only concerns one input. Autocompletion would be an example. It becomes awkward when more than one field is concerned, e.g. with show on select. And it fails altogether, if more than two inputs are involved or if the desired behavior is more complex. Generally any behavior involving two or more inputs should not be handled by one of the affected inputs, but by a dedicated controlling entity that exists once for every form. In fact, in many cases this would even be beneficial where only one input is involved, as it would enable one behavior for multiple input types without having to duplicate code.

Semantic Forms Rules would be an extension to MediaWiki building on the Semantic MediaWiki and Semantic Forms extensions. It would allow a much more dynamic behavior of Semantic Forms than currently possible.

The idea is to define rules consisting of triggers, conditions and actions. The conditions are evaluated when certain triggers are detected. Depending on the result the associated actions would be performed. Individual rules could be kept very simple, but the result of the evaluation of a rule would be stored and could later be referenced in other rules. This way rules could be chained and more complex rules could be constructed from simple ones.

Advantages

  • enables dynamic behavior of forms that could involve more than one or two inputs
  • provides one general approach for specifying dynamic behavior in forms instead of more and more parameters to input types being introduced
  • enables complex rules for dynamic behavior
  • "promotes" the controlling of dynamic behavior from input level to form level

Disadvantages

  • yet another element in the form description language

Examples

Rules are to be defined on the same level as info, for template and standard input.

Make title readonly on edited (i.e. already created) pages:

{{{rule|MyInitRule|oninit|nonempty|MyTemplate[Title]}}}
  {{{action|setreadonly|MyTemplate[Title]}}}
{{{end rule}}}

Show some div when a checkbox is checked:

{{{rule|onformchange|isset|MyTemplate[SomeCheckbox]}}}
  {{{action|show|somediv}}}
{{{end rule}}}

Show some div when a checkbox is checked and the title field is not empty at startup:

{{{ruleonly|MyInitRule|oninit|nonempty|MyTemplate[Title]}}}
{{{ruleonly|MyCBRule|oncall|isset|MyTemplate[SomeCheckbox]}}}

{{{rule|onformchange|and|MyCBRule|MyInitRule}}}
  {{{action|show|somediv}}}
{{{end rule}}}

Markup language for rules

Rules are to be defined on the same level as info, for template and standard input, i.e. they apply to the form as a whole. The standard case would probably be a block of rules below the standard inputs.

  • rule - Holds a condition that may be met by the form
    • 1st param (optional) - rule name (must not be the name of a trigger)
    • 2nd param - trigger (one of oninit, onformchange, onsubmit, onvalidate, oncall)
    • 3rd param - reasoner (e.g. equal, lt, gt, match, empty, nonempty, and, or, true, false ...)
    • 4th+ param - parameters for the reasoner
    • Example:
      {{{rule|MyInitRule|oninit|nonempty|MyTemplate[Title]}}}
  • action - Holds an action to perform when a rule is met
    • hierarchically below rule
    • 1st param - handler name (e.g. hide, show, setvalue, setstyle, add, remove, setreadonly, ...)
    • 2nd+ param - parameters for the action handler
    • Example:
      {{{action|setreadonly|MyTemplate[Title]}}}
  • end rule - Closing tag for rule
  • ruleonly - Holds a condition, but does not hold an action
    • same parameters as rule
    • saves the need for the end tag in an empty rule

Triggers

  • oninit - after the form is loaded and initialized
  • onformchange - after the form was changed (fired after a field loses focus and is changed)
  • onfieldchange - after a field was changed (fired after a field was changed, i.e. every single time a character is added to an input; do we need this?)
  • onsubmit - before the form is submitted
  • onvalidate - before the form is validated (do we need an onvalidationfinished?)
  • oncall - triggered when the rule is called (can be used to chain rules)

Reasoners

General rules for parameters

  • values of inputs referred to by templatename[fieldname]
  • literal strings given in quotation marks
  • parameters are stored by the rules so they can be accessed later by actions

Reasoners and their specification

  • equal
    • 2 parameters
    • becomes true if parameters are equal
    • may take additional parameters (e.g. type of parameters (String, Number), ignore case, trim whitespace)
  • lt/gt
    • 2 parameters
    • becomes true if first parameter is less/greater than second
    • may take additional parameters (e.g. type of parameters (String, Number), ignore case, trim whitespace)
  • match
    • 2 parameters: regexp, element to check
    • becomes true if 2nd parameter matches 1st
    • may take additional parameters (e.g. ignore case, trim whitespace)
    • stores matches for later use
  • empty/nonempty
    • 1 parameter
    • becomes true if parameter string is empty/not empty
  • and/or
    • 2 or more parameters: names of rules
    • takes the results of the named rules and combines them
  • xor
    • 2 parameters: names of rules
    • takes the results of the named rules and combines them
  • not
    • 1 parameter: name of a rule
    • takes the result of the named rule and inverts it
  • true/false
    • no parameter
    • always true/false

Action handlers

  • hide/show
    • parameter: id of element to hide/show
    • hide/show element
    • for inputs the element should be a wrapper div, not the the input itself
  • setvalue
    • parameters: the id of an input element, value
    • sets the value of the given input
    • caveat: the input must be able to react on this (e.g. the datepicker has two inputs that need to be synchronized)
  • setstyle
    • parameters: id of element to set style, style element (e.g. color, border,...), value
    • sets style of the given element
    • it might be beneficial to have this not limited to one element, but to give a selection rule instead of the id
    • the form designer may need in-depth knowledge of the element to style
  • add
    • add an element/input
    • I have no real clue how this could be done in a safe way.
    • Tentative idea: Give a standard SF field definition as parameter and use an Ajax callback. Or instead of an Ajax callback include the input right away and when the handler is called add it similar to the way the multiple forms functionality works.
  • remove
    • parameter: the id of an element
    • remove the element from the document permanently
  • setreadonly
    • parameter: the id of an input element
    • set the input to read only
    • this again might need some cooperation from inputs - no point setting the input line of a date input to read-only when the datepicker is still useable to change the value

Design ideas, consequences, thoughts

  • Reasoners for rules would be pluggable JS functions
  • Action handlers would be pluggable JS functions
  • Rules store their results for consecutive reasoning
    • a sound system for storing rule data is needed
    • this does not only include the direct true/false result, but also additional results.
      • E.g. the title field holding something like "1234 Some Issue" shall be split into "1234" and "Some Issue" and be filled into text inputs. This could be facilitated by making the results of the match reasoner available to setvalue action handlers.
    • just numbering the rules internally without regard for their user-given name should work
    • the user-given name would be just another attribute of the rule
  • Rules would be evaluated in the order of appearance in the form
  • Inputs must make sure that their value attribute is always available and up to date
    • as opposed to only created/set on validation
    • ok right now, I think
  • Are there additional constraints on inputs?
  • This goes in the direction of putting executable code into forms, so probably needs some close reviewing to avoid vulnerabilities.
  • What other triggers, reasoners, actions do we need?
  • Is the approach of having not very powerful reasoners and chaining the rules for more powerful reasoning ok? Should we have more powerful reasoners?
    • E.g. a reasoner that allows more complex conditions that directly include operators (and, or, xor, not)?
  • Is it wise to make the rule name optional?
    • The presence of a name is easily detectable by the fact that the first parameter does not correspond to any trigger.
    • But what if a trigger is added in some future version? It could collide with some peoples rule names.
    • It just feels a bit sloppy.
  • How can action handlers be made more powerful? E.g. how could the setvalue action handler set non-constant values?
    • Wikitext resolved via AJAX callbacks? Bleagh.
    • Is there a client-side wiki parser available? Or some other parser for whatever language (e.g. some JS subset) that would be save to use?

Specification

None yet.

Internal Design

None yet.

This page was last modified on 18 February 2013, at 11:07. This page has been accessed 4,905 times.