Re: TActionList and datamodules

Steve Troxell wrote:
How is it any more of a burden than an actionlist on a data module? Seems to be roughly identical to me. 

Uhm... not quite, really.
Frames have several disadvantages:

1) Putting them on a form, even invisible, takes screen real-estate
2) You will eventually concede to the temptation of mixing visual and
   logic code(please consider that an "action" *is not* a control).

I use it in a quite complex application without much problem. The frame just happens to be visible rather than invisible, but identical to what I described in all other respects. The separation from the form code has been very helpful. 

Yes, but you're mixing things up, unless you have very few menus, when
using datamodules you can - for example - place a TActionList on a
datamodule along side the routines that make up the actions work,
which in turn call the correct DB datamodule where all the data
management query-wise happens.

This approach makes things much, much easier to handle when it comes to
mantainance.

The approach I usually prefer is like this:

- The DB datamodule contains database components(can be a base
datamodule to inherit, since I'm confident I'll be using the
same components throughout the project) and its inherited ones
contain queries and support methods to turn data into objects.

- Now the logic module gets the data objects, manipulates them and
  either sends them back to the DB layer, or sends them to the GUI for
  display.

- The GUI raises actions

This works for me, without the need for a frame.

Now, my questions are: do you like this approach? is it worth to be
changed only to make something work?

The goal of a data module is to host data components. What's the difference? Yeah any nonvisual component *should* work on a data module and I have no problem with that. It's about as minor a deviation as whether Frame.Visible is true or false. Big deal. If I'm using a hidden frame as a component container, I find that an EXTREMELY minor detail. 

Because you don't consider the "meaning" implications, maybe.
A frame is, without a doubt, a visual "piece". It's meant to work on a
form, to be visible and invisible according to what you need, not
just invisible.

Plus, using frames "splits" the GUI, which can be good or bad
according to where the split happens.

Cheers,

Steve 

Andrew
.