If one uses the
#if
construct to separate component level behaviour, one winds up with large triggers, needing to page up and down to find out which bahaviour one is changing at the time.

I have seen no 'bugs' with their implementation (although you are right, the database is not normalised). The data type is maintained across all subtypes of the entity (functional and component). All three of the 'bugs' you mention are in fact my requests for improvement.

HI Ian,

Did you already detect the possibilities within the Model "U"?
Here you can define your own default piece of code for each specific type of Component-Subtype on entity and field level (see Help-File).

I didn't play with it, but I think with this you can at least define your component specific generic piece of code, which possibly leads you out to a more specific place (e.g. on entity level).

Wolfgang
 

Hi Iain,

I can not agree with you for one reason:

They had a proper database design for all those years with TABLE controls FIELDS.

Beside all desecrates of compatibility,
they made it a messy db-design and gave room for all kind of problems/questions like:

- How to provide/maintain a proper field template for code in different subtypes
- is there inheritence of field proc code and how can it be controled?
- if duplicating a field from one entity to another, how are subentity code handled

Success, Uli

P.S.
#includes or delegates to the subentity body
gives a lot of ways to avoid pagelong sourcecode.

Having only one place for field trigger allows a standard code
and the useof  #if to specify the exceptions only.

So the behaviour of a field is clearly documented in a single place.

Just that I'm not misunderstood:

A requirement to have flexibility in the modeled proc code
not only in (sub-)entity-related triggers,
but for the fields as well

is implemented that UCFIELD is no longer underneath UTABLE, but UGROUP now.

What is the problem now?

The current way vialotes the normalization of the database
and brings all kind of duplication / reduplication with it.

We have attributes which are constant for a field no matter which (sub-)entity it belongs to:
Field Interface, Data-type, ... have to be identical.

And we have the requested effect that trigger code can be handled according to each sub-entity.
But not only he can, but he must be handled for each sub-entity.
Gives all kinds of problems keeping format-deformat triggers in sync inside a database table.

What needs to refactor:

We leave to old UCFIELD as it was before.

Underneath the UCGROUP, we add a new entity UGFIELD which provides an overlay mechanism
like the one we have in UXFIELD.
The field triggers can be accessed via the subtype triggers form (like the uxfield ones for components).
 

The inheritace reads as:

if the UXFIELD is not empty => OK
if the UGFIELD is not empty => OK
if the UCFIELD is not empty => OK

Amount of changes:

So we have only to change the trigger editor to have an additional field-level for subentities
and the way the "default" code is fetched from the database.

Success, Uli