Problem description

By default, Community configuration 2.0 supports basic schema-based form only. This form only supports a set of primitive types (a number, a string, a boolean, etc.). While it is possible to create powerful configuration forms with primitive types, it is clearly not sufficient for more thorough configuration setups. For example, Edit check would likely need a more powerful configuration form. Similarly, if AbuseFilter were to migrate to Community configuration, it wouldn't be able to operate on top of the basic form system.

Solution

Community configuration 2.0 should allow even clients with complex needs to make use of its benefits (such as, a central place for the configuration – the configuration dashboard). This can be done by allowing client extensions to replace the standard form logic with their own logic. That way, the client extension could assume complete control (and complete responsibility) over the form, without having to modify CommunityConfiguration itself (or hack its way around the existing implementation).

With T360277 resolved, it should be fairly easy to make it possible for an client extension to define its own editor capabilities.