ibschema-dynform — List for discussion of the "DynForm" subproject

[Phil S. <ph...@sh...>]

Hi,

Things are pretty quite around here, maybe everyone is on holiday, not
interested or just lurking <g>

Anyway, before I move the 'technical' details of the DynForms subproject off
to its own (advert free) list, I will give a slightly more detailed
overview.  It is basically what I posted the other day, but with a bit more
padding to help with the understanding.

Anyone who wants to follow this up in a more than general way should post to
the DynForm list at SourceForge
(http://lists.sourceforge.net/mailman/listinfo/ibschema-dynform).


Overview
--------
To create a set of custom forms, components and 'experts', initially in
Delphi, that will allow the developer to 'develop' as normal within the
standard IDE, but to add the following main functionality....

The ability to..
- store and maintain a forms visual properties in a database
- store and maintain form 'modules' (visual and code) in a database
- update and add functionality/modules to applications via the database
- Add items to menus/toolbars depending on the apps DynForm requirement

Although initial development will be for the IBSchema RAD application and
will be done in Delphi, high level discussions with some Java developers
lead to the conclusion that a similar architecture could be achieved using
Java Beans.


TDynForm
--------
This will be a custom form class that has the ability to load/save its
properties and those of its children to and from Interbase.  The properties
that it will handle will include those like Font, Colour, Size, Position
etc. and also it could handle things like language (foreign not development)
and locale settings.  These properties will be stored as 'Application'
settings and 'User' settings.

It will also have the ability to add items to menus and toolbars as also
have 'state events' for use by status bars and progress meters etc.

As well as the normal form states (modal, non-modal, MDI-child etc.), the
DynForm will also have the ability to load its contents into a Panel or
similar component to allow browser/SDI style applications.

The DynForm could be used as normal by compiling it into the main EXE and
just the 'properties' managed by the database, or it could be used with the
DynPackage to create modular database driven applications.

DynPackage
----------
This will be a custom Package (BPL) and base unit that will 'hold' a DynForm
and 'publish' the methods to make the things work.  It will allow an
application to be developed modularly and controlled by the database.
Packaged 'DynForms' can be added to an application at runtime without
recompiling the main EXE.

DynPackageExpert
----------------
This will be an Delphi expert (File-->New-->DynPackage), that will enable
the developer to create a DynPackage.  It will basically create a new
Package project, but will also generate the 'base unit' and version
information.

DynMaintainer
-------------
This will be an application/plug-in/wizard that will allow the developer to
store and maintain the DynPackages in the database.  It will not only allow
the developer to 'upload' the BPL's, but also to update them and set/edit
the properties for each form in the database.  It will also allow the
developer to maintain the data required for the TDynFormBroker (see below).

TDynFormBroker
--------------
This will be a component that is used in the applications EXE.  It will be
responsible for 'downloading' the required DynPackage's from the database
either at start up or 'on demand'.  It will check that that client PC does
not already have the packages downloaded, and it has the correct version of
each package.  It will also be responsible for connecting the DynForms
'database' functionality to the main datamodule/exe etc.  It will also act
as the conduit for enabling the User to customise the DynForms properties
that are stored in the database.

DynDatabase
-----------
This will be the physical database and associated SP's/Triggers/UDF's etc.
that will enable all this functionality.  I think it is better to keep this
as a separate database rather than include it in the applications database,
but more for maintenance reasons.

Cheers

Phil