improve How behaviors work

Author: jensens

docs/backend/behaviors.md

@@ -34,6 +34,7 @@ This allows items of this content type to gain the additional functionality prov
 
 Overall, behaviors are an important part of the Plone content management system and allow for powerful customization and extensibility of content objects.
 
+
 ## Built-in behaviors
 
 | short name  | Title            | Desription                    |
@@ -119,39 +120,38 @@ After you apply the profile (or uninstall and install the custom add-on), the be
 
 ## How behaviors work
 
-At the most basic level, a behavior is like a conditional {term}`adapter`.
-For a content type, the default condition is, "is this behavior listed in the behaviors property in the FTI?"
-But the condition itself is an adapter; in rare cases, this can be overruled.
-When a behavior is enabled for a particular object, it will be possible to adapt that object to the behavior's interface.
-If the behavior is disabled, adaptation will fail.
+In Plone, behaviors can be globally enabled on content types at runtime.
+With add-ons, behaviors can even be enabled even on a single content object or for a whole subtree in the content hierarchy.
 
-A behavior consists at the very least of an interface and some metadata, namely a name, title, and description.
-This is also called a schema-only interface.
+### Interfaces and adapters
+
+When a behavior is enabled for a particular object, it will be possible to adapt that object to the behavior's interface.
+Otherwise, when the behavior is disabled, adaptation will fail or falls back to a more generic adapter, if any is registered.
 
-In other cases, there is also a factory, akin to an adapter factory, which will be invoked to get an appropriate adapter when requested.
-This is usually just a class that looks like any other adapter factory, although it will tend to apply to Interface, IContentish, or a similarly broad context.
+A behavior is at least a combination of an interface (also as a form field provider), metadata such as a name, title, and description, and sometimes an adapter factory with a marker interface.
+When a behavior is enabled, an interface is added to the content object to indicate its presence - it now provides the interface.
 
-Behaviors can specify a marker interface, which will be directly provided by instances for which the behavior is enabled.
-If you want to conditionally enable event handlers or view components, they can be registered for this marker interface.
+Behaviors without an adapter factory can be used either as a simple marker or to provide additional form fields.
+In this case, adapting a content object with this interface returns the content object itself, because adapting an object that already provides the exact same interface returns the very same object.
+Based on the now-provided interface, i.e specific views can be registered with the content type, or event handlers can be registered to respond to specific actions.
 
-Some behaviors have no factory.
-In this case, the behavior interface and the marker interface must be the same.
+In other cases, there is also an adapter factory (usually a class), which will be invoked (initialized) to get an appropriate adapter when requested.
+If an adapter factory is used an explicit marker interface is required.
 
-If a factory is given a marker interface different from the behavior interface must be declared!
+### Registration
 
-Behaviors are registered globally, using the `<plone.behavior />` ZCML directive.
-This results in, among other things, a named utility providing `plone.behavior.interfaces.IBehavior` being registered.
-This utility contains various information about the behavior, such as its name, title, interface, and (optional) factory and marker interface.
+Behaviors are registered globally using the <plone.behavior /> {term}`ZCML` directive.
+Internally, this directive registers a named utility that provides `plone.behavior.interfaces.IBehavior`, which contains combined information about the behavior such as its name, interface, factory/marker interface, and metadata.
 
-The utility name is the name attribute of the behavior directive.
-Historically the full dotted name to the behavior interface is registered as its name, too, but this usage is discouraged.
+### Lookup and provide
 
+Plone content objects have logic to look up the behaviors names registered from their types configuration, the Factory Type Information (FTI).
+At runtime, the logic provides the interface (or marker) from the behavior to the object.
+This dynamically provided interface enables the component architecture to react to this new interface by adding additional form fields, bindings events, enabling more specific views, and more.
 
-Behaviors are named adapters.
-They adapt an interface, for which they are registered and they provide another interface with new functionality such as attributes and methods.
+With an adapter factory in place, custom getters and setters for form fields can be implemented, or even new methods i.e. for calculations or to combine data can be added.
 
-Content types transparently look up the behaviors registered for a content type.
-If a behavior provides new attributes, it is provided as an attribute of the adapted object.
+### Additional information
 
 ```{seealso}
 The [README file of `plone.behavior`](https://github.com/plone/plone.behavior/blob/master/README.rst) explains the concepts and different ways to register a behavior in detail.