ln o gravityforms

ln-o-gravityforms

---

Future development goals for component:

• Finish implementing paged form rendering and logic
• Create paging indicators for the above
• Change confirmation and validation rendering to use ng-show/hide or ng-if on the main form body and the relevant blocks to enable use of ng-animate for posh transitions
• Migrate to ng-model for form data gathering
• Investigate implementing some kind of 'element-parser override' system, or 'input type override', where a developer can provide methods to render specific input types at the component config level and per-form to enable use of custom directives etc in forms.
  • The 'element-parser override' may look like the following:

    Markup: 
    <form ln-o-gravity-form="{{vm.formId}}" ln-method-map={{vm.gfParserMethodOverrides}}" ln-load-from-api="true"></form>

    Controller: 
    vm.gfParserMethodOverrides = {
      'select': cbSelectParse,
      'email': cbEmailParse,
      ...
    }

    function cbSelectParse(data) { 
      var _html = '';
      // Take care of parsing the field data add your custom markup to the `_html` variable and return it
      return _html;
    }

    ...

• cbSelectParse in this case, could be a controller method that a developer defines to parse the HTML for any 'select' elements on a particular form, so that custom HTML can be created per-input-type as required.
• This does present some issues though - how would the component enforce correct input naming, validation etc.
• Another way would be to allow input type overrides, this could be similar to the above, but perhaps, rather than a method-map, have an input-map, so:

    Markup:
    <form ln-o-gravity-form="{{vm.formId}}" ln-input-map={{vm.gfParserInputOverrides}}" ln-load-from-api="true"></form>

    Controller:
    vm.gfParserInputOverrides= {
      'select': 'select-to-ul',
      'email': 'ln-m-email-input',
      ...
    }

• There some complexities and compromises in this approach:
  • How would a developer pass any extra parameters to the component?
  • Would it need a set of properties and some template markup passed through?
  • The component would simply replace the original input and leave it in place as far as form structure goes
  • Validation etc would all still be 'default' component behaviour

On balance, the second of the two approaches may be easier,