Max
Don't mean to by offensive but
>> Paul Heinz calls "collapsed three tier"
Had me in tears - I agree you can do a 3T as a single app but you have to
be disciplined about the location of varoius logic
> 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
Alas the truth is out 3T is not a panacea
> centralised handling for standard changes, like changing field X implies
> that field Y should now read X * field W.
This I would do in the Database - another prob you'll face when you open
your DB
is all that nice logic that aint in your DB disappears
I agree that the DB-nonDB aware method choice was a bad one (if only they
could hide published properties)
We must remember D does not multiply inherit and I assume did not have
interfaces then
Re the 'duality; I not wanting to write all my own components have
approached this problem differently
For Example I have an 'Autocaption' object which I bolt on to dbaware
controls
(it creates a label from the DisplayLabel of the field assoc)
but I do it thus
TmwkDBEdit = class(TdbEdit, IAutoCaption, IDBControl)
private
FAutoCaption: TAutocaption
published
AutoCaption: TAutocaption read FAutoCaption write FAutoCaption implements
IAutoCaption
end
IDBControl enforces the parent to expose a function Field: TField
override constructor, destructor, CM_VisibilityChanged and a cupla WM and we
are done
Not a neat as you would do but a lot faster (and I can use GetInterface to
group manipulate the captions)
Cheers
Neven
---------------------------------------------------------------------------
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"
