Neven MacEwan asked:
> I knew if I taunted you I'd get something interesting - I note
> a lot of your additions to TFieldLink are required by the one-tier
> nature of Profax.
I not so sure that I agree with you there, but I'll go with the flow and
see where I end up. Currently we are moving our code towards what Paul
Heinz calls "collapsed three tier" so that we try to formalise the
linkages between the forms and the data modules. All of the additions that
I talked about earlier are there to support notifications of changes at
the UI layer to either the form, or the data module.
The notifications to then form I'd say are still compatible with three
tier as these are intended to do form level feedback things along the
lines of colour changes, flashing lights and buzzing noises.
The notifications of a UI change to the data modules are a little suspect
in term of 3T, but the primary intention there is to provide for
centralised handling for standard changes, like changing field X implies
that field Y should now read X * field W. In certain cases we have more
than one form looking at the same data and it simplifies things if these
sorts of UI changes are not spread about the place, and I guess that if
pushed we could create a better solution using some sort of components to
store these UI changes.
The other things that should be mentioned is that I am currently script
enabling all of the forms and data modules in ProfaxWin so that you can do
manipulations of stuff at the UI level, and also you can create the
underlying business objects and then script these as required. This level
of scripting means that the data modules are forced to be cleanly
separated from the forms so that you can script them without having nasty
things happen when the business rules are unavailable because they are in
an associated form. The idea is that when we complete scripting the data
modules we will have proved that we could move these all to a separate
program sans UI and have a working application that could act as a middle
tier.
Once we have this separation available then the only requirement is to use
a communication mechanism between the business rule server and the UI
application and we have a working three tier application. The fact that
currently it'll all be in the one application is not going to limit
further developments as we decide where to move in the market.
> >> the rather stupid duality forced into your control design by the
> >> implementation of data-awareness.
>
> Can you please elucidate (for those that are interested)
The central issue is one that the original Borland designer talked about
at one stage in discussion the implementation of the data-aware grid. Its
that the nature of data-awareness is conferred on a control by it
implementing TFieldDataLink and supporting properties, and responding
appropriately to the notifications fired at it.
Now consider a standard TEdit control. It has a bunch of behaviour that is
useful for non data-aware editing, like the Text property that you can
play with. Now consider how you would create a data-aware version of the
TEdit. You need to remove properties like Text because these not relevant
any more. So you have to go back to an appropriate base class and then
work forward adding in the data-awareness plus any extra behaviour that
you want that was implemented by TEdit and now TCustomEdit.
Now you have two control a data-aware editor TDBEdit and a non data-aware
editor TEdit.
One day you find that you want a nice new descendant of the TEdit, lets
say TLimitedEdit where you can only type in some characters. So you derive
from TEdit and make you nice new control. Then some one wants the same
facility available in a data-aware control, you now you either have to
decent from TDBEdit and cut and paste in all the new feature to create
TDBLimitedText, or you cut and paste all the data-aware code from TDBEdit
and add it into TLimitedEdit.
Its this "duality" that I was referring to where you either much replicate
the data-aware code through every control you want to use data-aware, or
you must duplicate control functionality to two separate descendants where
you want to reuse the data-awareness added earlier. This occurs thought
all the commercial Delphi component suites.
Our solution to this was to create a new control base class that does
data-aware stuff, and then derive all our controls from the same base
class. Then the difference between the data-aware and non data-aware
version of a control is just if the initialisation and the properties
published.
Cheers, Max.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
