Re: Question about Class Helpers

In article <47577c9b@xxxxxxxxxxxxxxxxxxxxxx>, Didier Gasser-Morlay
says...

I am all ears, what "proper design and coding techniques" would you
suggest to add some "dbawareness" to an existing hierarchy of edit
components

Turn the problem about....

Instead of trying to think how you can add DB awareness to an existing
control, instead try thinking about how you might make a DB framework
aware of those controls.

I did exactly that with my first real work in Delphi - an encapsulation
of the (then) Gupta SQL/API.

This was "inspired" by my previous life as a Gupta SQL Windows developer
where you could write this sort of thing in your application SQL code:

SELECT NAME, ACTIVE FROM CUSTOMER INTO :editName, :chkActive
WHERE CUSTOMER_ID = :CustomerID

When you fetched the result, the data from the NAME and the ACTIVE
column would be put INTO the referenced "containers".

The "containers" could be variables or (the fun part) GUI controls!!

(of course, it worked both ways, so that SQL parameters could also
reference GUI controls as INPUTS to an SQL command as well as
identifying them as recipients of results)

I realised that with RTTI in Delphi, the same thing was possible, so in
my implementation I could do exactly the same thing.


Now of course, I couldn't possibly anticipate ALL the classes of
controls that might ever be referenced in runtime SQL, and it wasn't
really viable to support only a specific set of classes, so I
implemented an abstract "binder" class with the sole responsibility for
"Get"ting and "Set"ting data from a specific control class on request
from the SQL API framework.

I implemented a set of binder classes (a binder class being truly
trivial) for the most common controls, TEdit, TListBox, TCheckBox etc
etc.

Of course, any controls that inherited from a class for which a binder
class was registered would be supported by that binder, OR you could
implement an even more specialised binder for that specific sub-class.


This meant that you didn't have to choose TDBEdit vs TEdit, you just
used TEdit. And if you wanted to use some other control, you didn't
need a TDB... version of that control, you just needed a suitable binder
class to be registered.


I eventually went further and supported "parameters" on container
references, so if you wanted to (e.g.) select some item in a list, not
ADD an item to a list, then you could do that directly in the SQL:

SELECT NAME FROM CUSTOMER INTO :lbCustomers[select]
WHERE CUSTOMER_ID = :SelectedCustomerID

The parameters were simply passed to the getter/setter in the binder
that could do with it whatever was appropriate or needed.


Just to see how far this could be taken, just for a demo I implemented a
binder class for good ol' TChart that supported so many parameters that
I was able to create simple, complete charts with only a single SQL
statement, with parameters to specify designated axis labels, data
series etc etc!


I still have all that code - Delphi 1.0 originally, but eventually
ported to 32-bit and then migrated to ODBC... not as "clean" as the
Gupta SQL/API version due to the inadequacies of ODBC itself, but the
same basic idea.

I keep promising one day to return to it - update it for ADO etc etc.

Just need to find those extra 3 hours in the day that I need to fit it
all in!

:)

--
JS
TWorld.Create.Free;
.

Relevant Pages

  • Re: Question about Class Helpers
    ... Instead of trying to think how you can add DB awareness to an existing control, instead try thinking about how you might make a DB framework aware of those controls. ... This was "inspired" by my previous life as a Gupta SQL Windows developer where you could write this sort of thing in your application SQL code: ... Now of course, I couldn't possibly anticipate ALL the classes of controls that might ever be referenced in runtime SQL, and it wasn't really viable to support only a specific set of classes, so I implemented an abstract "binder" class with the sole responsibility for "Get"ting and "Set"ting data from a specific control class on request from the SQL API framework. ... Of course, any controls that inherited from a class for which a binder class was registered would be supported by that binder, OR you could implement an even more specialised binder for that specific sub-class. ...
    (borland.public.delphi.non-technical)
  • Re: Setting form properties
    ... I call a SQL function I wrote in SQL ... > subform control, down to the form on the subform..... ... > determines what update rights a user has on the form. ... 10 subform *controls* on the tab pages, which may or may not be the ...
    (microsoft.public.access.formscoding)
  • Re: Give a man a fish?
    ... You can actually learn much about SQL just by switching your queries to SQL view. ... Next, you will be learning about forms, and the various controls you can put on them The controls and the form both have events that fire when something happens. ... Functions such as the Spacein your example are part of the VBA code, but you can use them in contexts outside of code. ...
    (microsoft.public.access.reports)
  • Re: Office 2000 / Office 2007 compatibility question
    ... My tools are chalked full of Active-x controls because I loves me a good tree- ... wheel is that I have to relearn the wheel. ... regarding SQL so I was wondering if you knew whether or not Access SQL got an ...
    (comp.databases.ms-access)