FWD » Core Development » Conversion Tools

This construct is emitted in tons of places (e.g., in Element arrays, as BY expressions, in PutField constructors, in Object arrays passed to LogicalTerminal.messageBox(), HeaderElement, with LogicalExpression for deferred, logical AND/OR processing). It appears in over 40,000 places in one converted application alone.

It would be nice to condense this call from

new FieldReference(someDMO, "someField")

to something like

someDMO.field("someField")

which internally returns new FieldReference(someDMO, "someField").

Even better from a business logic perspective would be

someDMO.someField()

but doing this would necessarily explode the API for each DMO, since we would have to add a new method for every field in the underlying table, so we'll avoid this approach.

Note that we will need to support extent fields as well, so we'll need a second version of the field method:

someDMO.field("someField", index)

These methods would probably best be added to the DataModelObject interface (currently just a marker). However, adding them to the DataModelObject interface means each DMO implementation class (or a common superclass) will have to implement them. Should we add a common superclass? I have avoided this so far to give downstream developers flexibility, but consider that we (or the customer) can write custom conversion rules to insert their own superclass between our superclass and the generated DMO implementation class (TODO: if we go this route, make sure this approach plays nicely with Hibernate's use of CGLIB, which they use to dynamically superclass our DMO implementation classes). The drawback to this approach is that it would require enough forethought as to future use at the time of conversion to know the superclass(es) a customer would want to inject.