by Funny how a useful new feature generates a requirement which
makes you feel that the feature is, well... great, but there is something
missing.
The new field templates in OpenRoad are very useful but it would be great
if they could work dynamically: if they could be bound with a frame
not only at edit time but also at run time.
Take a real-life example. I have an application with about 150 user
frames. About 120 of them all have standard controls: same set of fields,
mostly buttons, doing the same sort of work times 120. Obviously, we
have a field template which is included in all these frames at edit time.
In the current implementation of templates, we have the familiar story of
one change needing to be propagated 120 times. The ideal would be some
way of linking with the field template at run time, or at least having some
pre-processing facility which included it during image build. (By the way,
the new pre-processing facility goes part way but obviously it only handles
script. This new feature is supremely useful and is a must on any feature
checklist).
We can dynamically create most of the system classes and attach their
instances to the current running frame (via the create() method). But these
instances are created from scratch (the duplicate() method repeats something
that has already been created). There is no easy way of using the component
catalogue as a kind of dynamic library. There is a CompSource object
but that only takes frames, procedures and user classes as objects.
It's interesting to note that the OpenRoad developers saw this problem and
tried to solve it. If you look at the OpenRoad on-line help under Templates,
you'll see a reference to a utility called ReconcileApp in the Architect
product. I guess you would run it against your application and all
template references would be refreshed. Not exactly dynamic, but it's a
solution.
I wonder whether we'll see this in OpenRoad 3.5?
--
------------------------------------------------------------