| Subject | RE: [IBO] A simple question |
|---|---|
| Author | Helen Borrie |
| Post date | 2001-01-23T01:29:46Z |
At 12:22 AM 23-01-01 +0100, you wrote:
are by nature designed to enhance the kind of application that you build
for desktop databases...the grid mindset is the spreadsheet mindset - get
all the records over to the client in a grid and make the user scroll,
locate, etc. to reach the required records. "Grid features" generally help
to make this design approach more palatable to the user.
For truly effective Client/server development you need to drop that design
approach - your database is remote from the client application, at the end
of a thin wire. The UI has to focus on providing friendly ways to allow
the user to specify which rows from which tables they want to look
at. Ideally, you want to get at ONE particular row...for which you use
edit controls in a one-row layout. In practice, one often needs to aim at
presenting the smallest possible subset - up to 200 rows in a grid, for
example. A raft of grid capabilities provided for browsing huge record
sets becomes irrelevant. The need is for parameter capture and fast
searching that are fully optimized for efficiency and speed, both client
side and server side.
The TIBO* series of components uses TDatasource and lets you use the native
VCL and 3P components, thus preserving your existing investment - converted
application code, existing dependencies on expensive 3P stuff. That's
great. It's just important to realise that it also sells you into hanging
on to that legacy design which will never permit you to write truly
"server-centric" applications - it's a compromise.
The TIB_ series of data access components opens up for you a VCL that
interacts directly with the data access layer and makes no assumption that
the complete dataset is in memory. There is a comprehensive architecture
in the layer comprising TIB_Datasource and the TIB_* access objects that
fully encapsulates the things you want to do for a fully optimized
middleware layer...in short, there is very little (if any) code to write in
order to build a fast, friendly UI that is highly responsive to the
behaviour of a client/server database and keeps the wires clear.
I found it difficult and strange at first, having previously convinced
myself over the years that native Delphi + brilliant 3P controls were the
complete solution. Now I know differently. It was a case of "letting
myself fall backwards and trust that friendly hands were there to catch me"
- and I'm glad I made that shift.
I'm happy that the TDataset components are there for me to use with 3P
components for user facilities that don't need a "live-data" user interface
- such as QuickReport, TeeChart or a web application server. I regard
TIBO* as extremely useful also as a substitute for the BDE because it
*does* provide a painless route for converting existing IB 5.6 apps to IB 6
and beyond. That means you can offer your users a quick substitute while
you are educating yourself about rebuilding your app with a leaner UI and
more effective use of the features of the database. TIBO* has its uses
too for apps that need a generic UI over an optional range of back-ends -
although an ISAM backend is "apples" to the server database "oranges" -
this type of flexibility will never offer better database support than that
which services the lowest common denominator.
The simple answer to the simple question is that the native TIB_Grid
doesn't - and wouldn't - emulate the capabilities of TopGrid because, if
you choose to make that shift from desktop/spreadsheet design to true
client/server design, TopGrid and its ilk are overloaded with capabilities
you will never need - either they are irrelevant to server-centric design,
or the capability exists elsewhere in the architecture. If you decide the
transition is not for you, stay with TIBO* and enjoy the client-centric
features you know and love. :))
You might like to get hold of the Getting Started guide and try applying
some of the searching and lookup capabilities exemplified there to a test
project over your own database. It's just a taste, a sharing of the
initial experiences of one person during the "mindset transition". There's
no guarantee it will convince you, either. :))
In case you weren't aware of it, a great many of the properties and methods
of the TIB_* dataset classes are available to the TIBO* series through the
InternalDataset property, too. Because the property editors for the many
TStrings properties of TIB_* are not available in the IDE to the TIBO*
classes (they have to be accessed at run time) it's a high priority to
document these properties fully...take comfort...it is happening.
Cheers,
Helen
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
>TopGrid is a highly customizable grid. I haven't found a situation yet inA comment I'd make about 3P grids that use the native TDatasource - they
>which it didn't do what I wanted. What I really like about the component is
>the fact that it's both Data-aware and not, with no difference. Besides
>that it has some features like different kind of cell types (pull down,
>checkbox, combobutton etc).. I'd say most advanced grids have them..
>
>Hehehe. but at some point you have to make a choice and TopGrid was the one
>that got my attention..
>
>Though if anyone has a suggestion for a better, faster or IB_ native grid
>with at least the features of TopGrid (which I use extensively), I'd like
>to hear about that!!!
are by nature designed to enhance the kind of application that you build
for desktop databases...the grid mindset is the spreadsheet mindset - get
all the records over to the client in a grid and make the user scroll,
locate, etc. to reach the required records. "Grid features" generally help
to make this design approach more palatable to the user.
For truly effective Client/server development you need to drop that design
approach - your database is remote from the client application, at the end
of a thin wire. The UI has to focus on providing friendly ways to allow
the user to specify which rows from which tables they want to look
at. Ideally, you want to get at ONE particular row...for which you use
edit controls in a one-row layout. In practice, one often needs to aim at
presenting the smallest possible subset - up to 200 rows in a grid, for
example. A raft of grid capabilities provided for browsing huge record
sets becomes irrelevant. The need is for parameter capture and fast
searching that are fully optimized for efficiency and speed, both client
side and server side.
The TIBO* series of components uses TDatasource and lets you use the native
VCL and 3P components, thus preserving your existing investment - converted
application code, existing dependencies on expensive 3P stuff. That's
great. It's just important to realise that it also sells you into hanging
on to that legacy design which will never permit you to write truly
"server-centric" applications - it's a compromise.
The TIB_ series of data access components opens up for you a VCL that
interacts directly with the data access layer and makes no assumption that
the complete dataset is in memory. There is a comprehensive architecture
in the layer comprising TIB_Datasource and the TIB_* access objects that
fully encapsulates the things you want to do for a fully optimized
middleware layer...in short, there is very little (if any) code to write in
order to build a fast, friendly UI that is highly responsive to the
behaviour of a client/server database and keeps the wires clear.
I found it difficult and strange at first, having previously convinced
myself over the years that native Delphi + brilliant 3P controls were the
complete solution. Now I know differently. It was a case of "letting
myself fall backwards and trust that friendly hands were there to catch me"
- and I'm glad I made that shift.
I'm happy that the TDataset components are there for me to use with 3P
components for user facilities that don't need a "live-data" user interface
- such as QuickReport, TeeChart or a web application server. I regard
TIBO* as extremely useful also as a substitute for the BDE because it
*does* provide a painless route for converting existing IB 5.6 apps to IB 6
and beyond. That means you can offer your users a quick substitute while
you are educating yourself about rebuilding your app with a leaner UI and
more effective use of the features of the database. TIBO* has its uses
too for apps that need a generic UI over an optional range of back-ends -
although an ISAM backend is "apples" to the server database "oranges" -
this type of flexibility will never offer better database support than that
which services the lowest common denominator.
The simple answer to the simple question is that the native TIB_Grid
doesn't - and wouldn't - emulate the capabilities of TopGrid because, if
you choose to make that shift from desktop/spreadsheet design to true
client/server design, TopGrid and its ilk are overloaded with capabilities
you will never need - either they are irrelevant to server-centric design,
or the capability exists elsewhere in the architecture. If you decide the
transition is not for you, stay with TIBO* and enjoy the client-centric
features you know and love. :))
You might like to get hold of the Getting Started guide and try applying
some of the searching and lookup capabilities exemplified there to a test
project over your own database. It's just a taste, a sharing of the
initial experiences of one person during the "mindset transition". There's
no guarantee it will convince you, either. :))
In case you weren't aware of it, a great many of the properties and methods
of the TIB_* dataset classes are available to the TIBO* series through the
InternalDataset property, too. Because the property editors for the many
TStrings properties of TIB_* are not available in the IDE to the TIBO*
classes (they have to be accessed at run time) it's a high priority to
document these properties fully...take comfort...it is happening.
Cheers,
Helen
>At 13:15 22-1-2001 -0800, you wrote:All for Open and Open for All
> >You can use the TIBO components, which you will find on the Data Access
> >pallette. TIBOQuery is _strongly_ preferred over TIBOTable.
> >
> >I'm curious. What do you like about TopGrid? Perhaps there is a native IB_
> >visual component that will satisfy your requirements.
> >
> >Art Metz
> >AMetz@...
> >
> > > -----Original Message-----
> > > From: Thijs Kuperus [mailto:thijs@...]
> > > Sent: Monday, January 22, 2001 12:53 PM
> > > To: IBObjects@egroups.com
> > > Subject: [IBO] A simple question
> > >
> > >
> > > Hello there,
> > >
> > > It's probably a stupid question, often documented subject, but still:
> > >
> > > I'm trying to decide on which components I want to use, and have a
> > > question. I've been scanning over the components of IBObjects
> > > very quickly,
> > > but I noticed the IB_ strain doesn't support a normal
> > > TDatasource and with
> > > that not the standard controls.
> > >
> > > Now I'm using the TopGrid component, a very neat grid component,
> > > extensively, but this component only connects to the standard
> > > TDatasource.
> > >
> > > So, my question now is, what components should i use (the
> > > TDataset derived
> > > set or the native IB_ set) and still be able to use multiple
> > > transactions
> > > and the standard datasource components..
> > >
> > > Thx in advance,
> > > Thijs Kuperus
> > >
> > > ----------
> > > Also check our WebSite at:
> ><http://www.softtech.nl/>http://www.softtech.nl
> >
> >
> >
> >
> >
>
>
>----------
>Also check our WebSite at: <http://www.softtech.nl/>http://www.softtech.nl
>
>
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________