More additions to using the native comps...

IN PARTICULAR, the controls encapsulate every last thing you need to use
the smart searching, incremental search, etc., with not a scrap of code to
write. To me this is the ESSENCE of a fast, effective, consistent,
maintainable UI for client/server work.

Add to this things like set-sensitivity in searches and locates (the
controls automatically know where to go within a filtered set) and the
potential that is in the TIB_Datasource for developing custom controls...

Notwithstanding the TIBO* components take advantage of a great deal of the
server-centric architecture of TIB_*, I perceive two really quite distinct
connectivity options in the two series. To a considerable degree, TIBO*
panders to the "fat client" habit that BDE programmers pick up, become
dependent upon and carry as baggage. That can be a useful thing because it
helps to ease the mental transition from file-server to client/server. But
it also perpetuates the native Delphi approach of making the data access
classes the slaves of the GUI.

It's an approach that DOES leave the route open to scaling to a different
database; but it's not long before you start seeing needs 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. Woll-2-Woll, Orpheus and the like have done very well out of this,
producing better and better GUI masters for the TDataset slaves and forcing
more and more data-layer functionality into the UI layer.

That's why TIB_* really makes you rethink your perception of C/s
programming and opens doors you didn't know were there in developing
object-oriented interfaces for relational data structures.

Native IBO is about a GUI that takes care of just what the client user
needs and hands everything else over to the data access classes and thence
to the server. The data access classes in this architecture are in
charge. Newcomers often complain about all the "richness" in native IBO
until they finally get hold of that fundamental difference. After that,
the IBO users allow no upper limit. Requirements they couldn't have
conceived of six months before keep Jason constantly running uphill with
the sub-release levels incrementing daily, sometimes! <g>

H.

At 05:54 PM 05-01-01 -0600, you wrote:

>Nick,
>
>Thanks for the response. You certainly made a good argument for using the
>native components and after I finish this conversion, I will have to take a
>closer look.
>
>Chris Landowski
>
>----- Original Message -----
>From: "Kaputnik" <delphi@...>
>To: <IBObjects@egroups.com>
>Sent: Friday, January 05, 2001 5:47 PM
>Subject: RE: [IBO] TDataSet vs. Native
>
>
> > Hi....
> >
> > well, the IBO Native components are not only a carry over but more than a
> > good replacement....
> >
> > Well, where to start....
> > First, the IB_xxx stuff has no persistent fields, but almost every
>settings
> > stored in the dataset itself. That has some drawbacks, but much more
> > advantages...This makes configuring data-aware components a no-brainer.
> > Simply assign the field and datasource, and everything else is configured.
> > The grid itself is fabulous.....headers indicate possoble sorting-orders
>and
> > clocking them resorts the query, without closing and repoening it....also,
> > switching datasets at runtime fo the grid is no problem...as all settings
> > are stored in the dataset, the grid configueres itself accordingly.
> > Also, the Grid accepts in-place-editors that you simply drop into the
>grid.
> >
> > The Lookup-components are also a hit...they have not simple dropdowns, but
> > complete picklists with several columns with headers and are
> > sortable(!!)...you'll need 3rd-parties to do that with the
>TDataset-classes
> > which almost cost as much as IBO itself :-))
> >
> > Added to this the state-awareness of the components with changing colors
> > (colors indicate edit, browse or search-mode), and the complete built in
> > search-capabilities with almost complete QBE-syntax, you have a great
> > framework to build cool and user-friendly applications.
> > Also, there is support for incremental searching built in right into the
> > Grid, but also there are seperate controls to do this.
> >
> > Also, the Datasources of IBO use a messaging-subsystem to announce, when
>any
> > components linked to them are focussed....and the IBO-bars can receive
>this
> > focus, making e.g. MDI-apps with centralized bars a breeze....if one form
>is
> > selected, the bars are focussing on its datasource without code....and
>there
> > is not oly a navigation-bar, but 6+2 bars, all capable of beeing included
>in
> > standard-toolbars.
> >
> > There is much more to the native components, but I hope, you got a first
> > impression.
> >
> >
> > CU, Kaputnik
> > (Nick Josipovic)
>
>
>

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