Add the ability to append/prepend the builder list based on decorator/field

[Anthropic]

Enhancement

As a user/developer, when I want to dynamically modify templates I should be able to add builders to fields without the need to modify/customise the actual builder code.

Expected behaviour

I expected to be able to pass a list of fields and the builder with a flag for prepending or appending

Related issues

This stems from issue https://github.com/json-schema-form/angular-schema-form/issues/779#issuecomment-253886014

@json-schema-form/angular-schema-form-lead

[kyse]

Interesting thought. But sounds like you'd need to decorate schema forms builder provider to add logic to conditionally add builders. Or an easier way would be to add a wrapper to each builder from a config method to check the form builder conditions.

angular.module('blah').config(wrapBuilders);

wrapBuilders.$inject = ['schemaFormDecoratorsProvider', 'sfBuilderProvider'];
function wrapBuilders(sfdp, sfbp) {
    var currentDecorator = {};
    angular.forEach(sfdp.decorator(), function wrapDecorator(decorator, name) {
        currentDecorator = { decorator: decorator, name: name };
        if (angular.isFunction(decorator.builder)
            decorator.builder = wrapBuilder(decorator.builder);
        else if (angular.isArray(decorator.builder)
            decorator.builder = decorator.builder.map(function(b) {
                return wrapBuilder(b);
            };
    });

    function wrapBuilder(builder) {
        return function conditionalBuilderWrapper(args) {
            // Apply desired conditions for builders.  Append, Prepend, Pull from setting of array of fields you want, etc.
            // You have access to current.decorator, current.name, builder, sfbp.builders.[buildertype].
            if (your logic) {
                builder(args); // or builder.call(null, args, otherargs) if you need to bind something to its args.
            }
        }
    }
}

I think you can also define builders individually per field's form def?

[Anthropic]

Yes, I was going to re-write some of the decorator/builder process as I don't think the current way decorators operate is flexible enough. For example I have an add-on that does not display and is therefore independent of decorator, but I can't easily provide a single include that says, "load for whatever decorator the person is using" so I need to look at modifying that and at the same time update the builder to handle similar behaviour and optionally not be restricted to decorator so add-ons can be supplied as a single include and so could a builder that needs to attach itself to a list of templates without caring about which decorator it is run within.

[kyse]

Needed this myself today, so here you go.

https://plnkr.co/4xXY7o

Adds two new methods to schemaFormDecoratorsProvider

• defineInheritedDecorator(name, fields, inherited)
  • Create new decorator inheriting from existing decorator (or target default decorator). With this you can create new decorators without redefining templates/builders for types you don't intend on updating. You can use this to add some global builders to modify the form functionality without breaking default stock sf functionality for other form instances.
• addBuilderToDecorator(builder, options)
  • Add a builder to a decorator.
  • Options:
  • name: add builder to sfBuildersProvider.builders object if name is supplied.
  • before: add to beginning of array, or before target builder.
  • target: string or builder function reference to place builder before or after.
  • replace: string or builder function reference to replace with new builder.
  • types: array of strings or comma separated string of field type's names to limit adding builder to.
  • Handles copying builder array if needed to avoid altering default builder array used by bootstrap decorator
  • Bootstrap decorator should just use sfBuilderProvider.stdBuilder array so this comparison would not require storing the array in the config body.
  • Handles cases where decoratorType.builder is a single builder function rather than an array of builders.
  • Handles cases where decoratorType.builder is null.
  • Handles cases where replace target is not found (defaults to end of array, unless before option is specified).

Disclaimer: not fully tested, so write yourself some test/coverage for it if you use it.

Cheers.