CUBA platform : designing screens for a class hierarchy

I have 4 entities :

Person (name, email, etc.)

Counterpart extends Person (bank & payment info, etc.)
Customer extends Counterpart (discount, crm info, etc.)
Provider extends Counterpart (supply, products, etc.)

I need 3 screens, one for each except Counterpart, and I hesitate among several design possibilities. The goal is to avoid duplicate fields in a given screen where a screen already exists for the parent entity. E.g, if I designed a screen for Person, I would like to reuse this screen in some way in the screens for the children entities (not duplicating fields for e.g 'name').

I came with the following options:

Was very interested by platfom screen/xml inheritance, which seems to fit quite well my problem, but it does work only for platform screens, not one designed by user, sadly.
Design a (smart) screen where you can select entity type in some way and then the screen adds dynamically GUI components to handle specifics of the entity. Screen will be more complex and managed essentially by code and not visual design, which annoys me (why having a visual designer then). Except if one have design tips.
Design 3 distinct screens, but have a way to reuse e.g fieldgroups designed visually previously. I know that I can completely generate a GUI component in code.
Design 3 editor screens each for entity specifics and have some way to combine/embed them, but in that case I will likely have to change the entity model from inheritance to composition to make it much easier.

For now I'm leaning towards option 2), using e.g frames collapsing themselves when the specifics they handle is not relevant anymore, but I'm afraid it will not work because the Editor is bound to a specific class.

What experienced developers with CUBA would advise ?

Solution

It depends on amount of controller's logic which you can potentially re-use. Does it really pay off to complicate your code structure for code reuse? I think it should be at least 10 common fields with complex validation / dynamic appearance logic to make reuse.

I would go with frames. Extract reusable part of layout and associated logic into a frame, then embed frame into entity editors.

By using frames you can decompose any bulk screen into smaller and more manageable pieces.

Also, field validators, custom field generators, table style providers, formatters etc. containing non-trivial logic, can be extracted to be upper-level classes. Thus they can be reused throughout the whole project.