At 12:18 PM 06-01-01 +0100, you wrote:

>Hello Helen,
>
> > that the fat
> > client VCL can't meet without a LOT of manual code, i.e. more
> > fat. Look at
> > some of the monstrous data-handling monoliths we have all had
> > to write
> > during our time in TDataset country. It's where RAD turns on
> > itself and
> > makes hard work out of something that a different class
> > ancestry would have
> > avoided altogether.
>
> > The Delphi VCL is heavily focused on the GUI - its database
> > functionality
> > is all about bringing data processing right up to the surface of the
> > GUI.
>
>Are you talking about BDE TDataSet from Delphi 3 or does this also include
>the virtualized TDataSet from Delphi 4 and later?

The virtual TDataset began at Delphi 3. I'm not saying there is anything
wrong with TDataset for the job it was designed to do, which is to provide
a data interface for desktop databases. But it's intended to bring data
over to the client which then determines what to do with it. Except for
string masks, there is nothing in it to preset data
attributes. TDataset/TDatasource has no modality to support two C/S basics
- preparing and searching.

>I liked the concept of
>virtual TDataSet a lot. I realize I'm not qualified to argue with you, but
>still I don't see how TDataSet forces anyone towards a fat client.
>Honestly, I would love to hear some arguments to support your statements.
>Could you explain this a bit more, please. Perhaps I yet have to go through
>a mental transition such as you describe.
>
>Let's suppose I use IBX for example. I can define views on the Interbase
>server to make client select statements simpler, with triggers so they
>appear to the client as updatable tables. Most of the development is thus
>done on the server. Once that's done, I enjoy the fact that writing a client
>application is very easy and fast - I'd drop a few TIBQuery components, data
>sources, data-aware controls and I'm done. When I need some data which does
>not need to be linked with the GUI, I'll use the TIBSQL component. All (or
>almost all) functionality is coded on the server in views, triggers, and
>stored procedures. Is this scenario what you call fat client?

Yes, it is. IBX has even less capability than the BDE to moderate data
requests. It doesn't position or reposition correctly in the buffers and
you have considerable work to do *in each control* to get datasets to
display and refresh as the user wants them. You need to add
TClientDatasets (= lots of fat) to emulate the key-sensitive
behaviours; or just not support them. Native IBO does all of this
stuff; and it doesn't require you to fetch all records in all cases. With
IBX, all commits and rollbacks close all datasets in a transaction.

But IBX *is* adequate for trivial applications such as you describe. It's
OK for a simple web app, for example, which doesn't require a GUI. But for
the things users really need to do in a C/S client, like searching,
query-building and so on, it is going to be a LOT of work and a lot of
handlers needed in controls.

The third-party vendors have done a very effective job over the life of
Delphi to produce specialised data-aware components to hide some of this
stuff but it's still pushing data layer work into the GUI. That was my
point. Consider the features of grids as a prime example. Because the
native DBGrid is so under-featured, there have been wonderful opportunities
for 3Ps to produce grids that can do whatever the heart desires. But all
of this stuff *has* to happen in the control because the
TDataset/TDatasource framework doesn't do it. The
TIB_Dataset/TIB_Datasource does; and it makes it completely consistent, no
matter which TIB_* control you use because it's all happening in the data
access layer.

With TDataset,etc., anything like incremental searching, building SQL
strings, specifying formats, column alignment, etc. has to be done in the
controls, and it has to be done for every control. With the thin GUI
architecture of native IBO, you do this once, and you do it to the data,
not the controls. For domains, you do it once at connection level and it
applies to all datasets in the application.

>I like those rare moments when a new idea makes you start thinking
>differently. I have just recently started using IBO and until now I had no
>such experience of enlightenment. What I see at the moment is:
>
>- TIB_Query with so many TStrings properties that this makes me feel I'm not
>using a compiler but writing some kind of script, like VBA.

Really??? I can't see any similarity between TStrings and VBA.
But the collections CERTAINLY need some useful, comprehensive documentation
and probably more editors...

>BTW, what about properties like FieldsGridLabel, isn't that GUI related?

It's GUI *related* but it's not done in the controls, it's done in the DA
layer and it's done only once. Column layouts in grids are GUI-related but
you're making the data dictate the interface, not the other way
around. Native IBO grids don't surface a Columns[] array because they
don't need it!

>(but then the VCL TField is no different, either)

Well, the TField *is* different. It's a data object, not a GUI
object. And, yes, you can set up masks, et al., and there's quite a lot in
common between what you do with persistent field objects and what you do
with TIB_Column arrays. TField is generic, though, so there are pieces
missing that are important for client/server.

>- all those .imp and .int files which Delphi doesn't recognize for syntax
>highlighting or code insight. That's very annoying, and I would appreciate
>if someone can provide a workaround.

Are you using Delphi 5?

>- a strange naming convention throughout the code, using underscores (a lot
>of them).
>- a few very basic and almost useless tutorials (but I admit I have made no
>intensive search yet for other sources of information)

The sample apps are more useful - well worth a closer examination.

>- a lot of code to read and try to understand (but I admit I haven't even
>started)

There's a huge helpfile...it's not necessary to read and understand the
code to use the components, is it?

>- many various UI components, but they only make sense with IBO.

That's true. <g> Actually, they only make sense with TIB_Datasource, too.

>Please I'm not trying to criticise. I'm showing you my feelings and probably
>the typical feelings of the average programmer when they have their first
>look at IBO and what probably scares them off. Please I don't mean to start
>a flame.

It certainly scared me off 2-3 years ago, so much that I rejected it and
plodded on with the BDE. But, oh boy! I have had cause to regret that now
that I've begun using it. Yes, it's tough to get started in it and I know
that I would have been stuck without the list support. Even so, in
retrospect I was most daunted by the hugeness of it and frustrated by the
collections properties.

I addressed the hugeness by getting hold of TIB_Statement and TIB_Dataset
help and listing the properties I absolutely could not do without. I
eliminated all but 10. I wrote a very successful first app with just those
10 properties and hardly any handler code.

oh dear, 5.10 a.m., I should think about going to bed.

H.
All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________