My Actual Application is of Sort B.
I do not use a Form Designer, but a Database-based Repository of Forms
and BO'S and Fields and so on.
Forms are of different types, and are simply a row in a special table.
Forms contain BO's (going down to IB_Queries and related Lookups) and
Fields. These are mapped together via Links (for Master-Details) and
hyperlinks to other forms.
Forms are designed mainly by setting the Form-Type (typical MD-Form with
a grid below and several tab-sheets, chart-forms, PIM, Reports, pure
data-entry forms and so on).
Form Fields are layed out via a special schema: a form has a maximum of
4 columns, adn the fields are simply specified by column and
sequence-number in the form. Fields are of varying height, but never of
varying width.
There is a small designer for building applications, which shows forms
in Wysiwyg, but no drag&drop (might come later).
Special views allow the Application to get the access-rights for tables
and views for the current role and as forms are always related directly
to one base-table (the master) the granted rights to that table are
responsible for the form being accessible to the user or not.
I do not use much application-logic (and if so, I create a special
form-class for it), but make excessive use of triggers and Stored
Procedures to create workflows. Access to the Application Data is
granted on database-level for Tables, and logical access is granted
through the use of views.
The logical access to the data is done either ROLE-based (the user can
either see the time-sheets of all users by directly going to the table
or he can see only his personal time-sheets through a view. This is done
through the use of different forms with same names which are then shown
in the same group of forms in the navigation-tree). Also, there are
TEAM-based access rules (again through a view) for e.g. Sales-Leads,
Service Requests and so on. Complex Reports are done via Report-Builder,
and here I thank god for their design of the Data-Dictionary (mentioned
in an earlier post). As the DD is based on Pipleines and therefore
accessing Database-Table (or views) I was able to construct special vies
which are combining the Interbase-Schema (RDB$xxx) any my repository to
map BO's Tables and Fields and their names to the DD in a way that the
user will a) only see tables/views he has access to in the APP as
defined by his role and b) he will never see the real DB-schema but only
the Table-Aliases and Field-Aliases as defined in the repository. Thus
the end-user is able to design his own reports without a fear that he
can access data he is not meant to see and also he is not confused by
naming-differecnes of the Database and the Application. He see's form
names instead of table-names and the field-names are also familiar from
the UI.

Repostitory-information is stored via a streaming-mechanism to the
client in a subdirectory after initial download of a Form (including all
related information) so the network-load is minimal for running the
repository-based application after an initial download. This means,
every object in my BO-layer has a streaming-mechanism and a loading
mechanism. If it is initialized, its looking for itself in the local
storage, and if it does not find itself it will build itself from the
server-repository and stream itself to the local repository when free'd.

This IBO-project now took me almost a year (in my spare time) and will
for sure need another half year before it gets to its 90% mark, but more
than 60% of it are up and running and what I already got works smoothly
and performant. The underlying design is more than 2 years old and riped
for a year in my head before I did start the project.

The design of the abstraction layer for the generic application was
crucial to the success of the project and I urge everybode running a
similar road to sit down and design long before starting to code. The
database-schema for the repository is also not of insignificance.

Ah, this post grew longer than intended, but finally my advice:

My tip is always to go the route B if you have the time and will to do a
robust and flexible/open design, and Route A if you need to shoot sharp
and quickly :-)

Nick Josipovic

BIT Institute
Prof. Dr. Franz Steffens
University of Mannheim
T: ++49 621 181 1621
M: ++49 179 133 44 16
S: ++49 621 181 1622
F: ++49 621 181 1618

nick.josipovic@...

> -----Original Message-----
> From: Damian Dowling [mailto:damian-dowling@...]
> Sent: Monday, January 14, 2002 5:18 PM
> To: IBObjects@yahoogroups.com
> Subject: [IBO] Questions about new project and IBO
>
> Hi all,
>
> This might be slightly OT but it is about IBO as well.
>
> I am just about to start another project with IBO (YES!) and the

design

> allows for one of two routes to be taken and i want to find out which

is

> best with IBO.
>
> Route A.
> There is a main MDI program and a lot of packages containing the Child
> Forms which are dynamically loaded at runtime - This i have done

before

> with IBO and although this project is bigger i do not expect any

problems.

>
> Route B.
> Again there is a main MDI program, but this time it has an embedded

Form

> Designer which the end user/developer will use to create the Child

Forms

> the form structure and scrips are held in the database.
>
> My questions are:
>
> With Route A has anyone encountered problems with IBO v4 and lots of
> packages e.g. 100+ (In the last project i used v3)?
>
> With Route B - has anyone tried this with IBO components? If so what
> problems did your encounter, if any?
>
> I have tested Dream Designer and it works well, but i need the

designer to

> be all on one form, and i have had problems getting Dream Designer to

do

> this. Can anyone suggest an alternative?
>
> Thanks
>
>
> Damian Dowling