We're trying to create a Custom Field that has inner fields, namely in a simpler form a TextField decorated with icons within the field.
We understand how to make it a template, and how to instantiate it.

What I would need to know is how could we mark it (annotation, method, interface, etc.) so that in Scout Explorer it could understand that this template can take other fields (as for example a GroupBox or SplitedBox)?
Comparing GroupBox or SplitedBox we couldn't find any common marker that would instruct the Scout Explorer (hopping it isn't hardcoded there)

As an update, if I directly extend GroupBox the ScoutExplorer works correctly (after closing and opening the view). But I don't feel that I should extend this one, but instead the AbstractCompositeField directly. What would be the better option?

The Scout SDK offers the relevant operations on an element. So that a custom field implements ICompositeField is not enough information to decide which children it may contain.
E.g. a RadioButtonGroup may only contain buttons. A GroupBox can contain each field. And both implement ICompositeField.

Which operations that are available on an element is configured in the Scout SDK. And for GroupBox it is already configured. Thats why it works as soon as your custom field extends AbstractGroupBox.

If you want your field to extend AbstractCompositeField directly, you must teach the SDK what operations that may be available for that specific field and how it should be presented in the Scout Explorer View.

This can be done by implementing a custom Eclipse Plugin and then using the org.eclipse.scout.sdk.ui.formField Extension Point.
Using this extension point you can define how your custom field should behave in the Scout Explorer. See the following example for RadioButtonGroup:

So if a form field implements IRadioButtonGroup, the RadioButtonGroupNodePage takes care of how this field should be presented in the Scout Explorer and which operations (context menus) that are available.

Unfortunately there is no meta information in the Scout Runtime that defines which child elements an element may contain. That's why this must be configured in the Tooling.

Hope this helps and if you have any further questions on how to extend the Scout SDK, don't hesitate to ask!

Thanks for the help.
I've been reading the code, and I believe I've understand it.

It would be very nice if the Scout Explorer could also inspect the Template annotations (as the Scout Object Property) and set available the correct context menu actions for it. (for what I understood the actions and handling seem similar..)