> difficult to maintain?
>
Not at all. They are much easier to maintain as long as you do not
change anything about your application or the backend you are using
that conflicts with the code that implements the control. The problem
is, those kinds of conflicts happen a lot. My point is that when they
do, you can spend more time coding workarounds than you would spend
coding your own interface to the standard controls in the first place.
> I'm working on an application server framework, also including
basic
> business objects. If I provide easy linking with db-aware controls
I
> need to hold their data in a TDataSet descendant. An alternative
way is
> followed by tiOPF which contains so called "persistent object-aware
> controls". Also I could leave it to the user to create the
link
> between controls and the object's data.
> Comments?
>
My comment is that the guys that created these components made them
simple to use by hiding information. You can get the same effect as
the data aware components using standard components. We have written
our own library that binds all the standard windows controls to
queries. We have completely eliminated the BDE and have written
another library that goes directly to ODBC to communicate with the
database. The way we have implemented both libraries that is
different than the shrink wrap ones we have used is that they are
highly granular. That is, there are both very high level and very low
level calls you can make to our libraries that allow for complete
control. For example, we have a BindControl call (a separate one for
each standard control) in which you pass the control as a parameter
along with a pointer to a library structure. After that single call,
everything is handled by the library both to and from the control.
However, you can do other calls that override just about anything you
need to override in terms of the behavior of the control. Since we
wrote the library, we can add any other functionality we need when
that need arises.
In general, my advice is this: Learn how to write software using the
basic underlying language, in this case, Pascal. The main reason we
started using Turbo Pascal many years ago and moved away from IBM
Compiled Basic (written by Microsoft) is that the Pascal language was
based on an ANSI standard, and Basic was not. If you do that and
learn how to abstract and modularize (library) your code, you will
find that you can make your own code just as easy to use as the
shrink wrap solutions, but still maintain complete control over how
it works.
We try to use the Windows API in our libraries for greater control.
APIwithDelphi is a group that is all about how to use Delphi in this
way:
http://groups.yahoo.com/group/APIwithDelphi/
We are in the process of porting a lot of our code to Linux and when
you write you own libraries, you can achieve platform independence.
We are currently investigating FreePascal for this with some success
already.
Glenn Lawler
--- In [email protected], constantijnw <[EMAIL PROTECTED]> wrote:
>
> Glenn Lawler wrote:
> > >What are compelling reasons not to use db-aware controls?
> >
> > When you are writing Client-Server systems, using standard
controls
> > instead of db-aware controls gives you a great deal of
flexibility.
> And more effort.
> > For example, all the db-aware controls I have used will lose their
> > data
> > as soon as you disconnect from the database. When using standard
> > controls. You can connect to the database, run a query to return
data,
> > populate your controls, and disconnect. This frees up a database
> > connection. Most commercial Client-Server databases have a non-
trivial
> > cost for each simultaneous database connection.
> >
> Right, but in my case it's a multi-tier setup.
> > There are many other reasons, this is just one. If you want your
> > applications to work exactly the way you want, using someone
> > else's component could cause you as much work as writing you own
> > code when trying to get around undesired component behavior.
> >
> You mean that db-aware controls are more complex and therefore more
> difficult to maintain?
>
> I'm working on an application server framework, also including
basic
> business objects. If I provide easy linking with db-aware controls
I
> need to hold their data in a TDataSet descendant. An alternative
way is
> followed by tiOPF which contains so called "persistent object-aware
> controls". Also I could leave it to the user to create the
link
> between controls and the object's data.
> Comments?
>
-----------------------------------------------------
Home page: http://groups.yahoo.com/group/delphi-en/
To unsubscribe: [EMAIL PROTECTED]
YAHOO! GROUPS LINKS
- Visit your group "delphi-en" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
