BorlandTalk.com

Andy Gibson · Guest

I've been using Delphi since Version 1, and over the course of time, I've
worked on a number of projects that all do common basic things different
ways. We are looking to standardize on some of the basic techniques used to
implement these standard tasks and so I thought I'd see what everyones
opinions are on the issues. (if anyone would like to add other issues, feel
free)

Datasets on datamodules vs Forms :

For your everyday form which lets the user edit a piece of data, should
datamodules be used to host those datasets? If you use a datamodule, it
keeps things nice and clean. However, if you allow multiple instances of the
form, then you need to have more than one data module and then you have to
bind the data aware controls to the datasources at run time.
Putting datasets on forms means each instance of the form has its own
datasets at run time wihout the need for additional coding. This doesn't
really cause any problems except for the fact that it clutters the form up
at design time,
and datamodules can still be used for truly shared 'singleton' type
elements.

Persistent fields vs Dynamic Fields :

I know there was a thread recently about this, but I'll include anyways.
Without persistent fields, you can't have lookup fields or calculated fields
unless they are created at run time (not too RAD). You could push the
calculated fields into the SQL if they are static and won't change when the
row changes. Changes in the database or even using alternative databases
which result in different field types can cause problems on the
client side with persistent fields mismatching the source field datatypes.

Calling Forms to Edit Data :

Assuming you have a form which edits a particular entity given an entity ID,
where do you put the function to create and display the form? You could have
a unit dedicated to containing stub procedures whose sole purpose is to
create an editor, pass in the parameters open it up and return whether the
form was closed with an OK.

i.e.

function EditItem(AnItemID : Integer) : Boolean;
var
frm : TfrmItemEditor;
begin
frm := TfrmItemEditor.Create(nil);
try
frm.LoadItem(AnItemID);
Result := frm.ShowModal = mrOK;
finally
frm.Free;
end;
end;

You could also have a class function on the form which contains the above
code to create, load and open the form, but then this means that any item
calling the editor needs to know about the individual class of the form.
With the previous solution, any part of the application needing to edit an
item only needs to know the location of the 'EditItem' function which could
be in a unit dedicated to containing these stubs used to launch forms.

Another issue is whether the form loads its own version of the item to edit
it, or whether it is passed a datasource which points to the item to edit.
Passing a datasource/dataset to a form means that there is no need for
another trip to the server to fetch the data required for the editor. OTOH,
to create a standard editor form for a particular item means that all
datasets holding instances of that item need to have the field names exactly
the same in order for the editor to access the item from that dataset.

We are trying not to mix and match the techniques used for these basic
functions (and others as they crop up) so I'm just curious as to what the
general concensus is.

Cheers,

Andy

Alessandro Federici · Guest

"Andy Gibson" <delphi_pa (AT) hotmail (DOT) com> wrote

[...HIT THE NAIL ON THE HEAD...]

Dave Nottage (TeamB) · Guest

Andy Gibson wrote:

Ross · Guest

Andy Gibson wrote:

Buch · Guest