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,