All,

I am posting my response to a question I received about “Build Your Own Framework.” First, the question…

Ken,

First, I'd like to thank you for your book. I'm getting a lot out of it and you're clearing up a lot of mysteries. I especially like your definition of Business Objects - Microsoft and others seem to think that a BO is indistinguishable from a table object (it just saves the data). I've often thought that a limiting (and not normalized) view. So, your ideas are a welcome treat.

I would like to ask a question if you have a moment. On page 51, you say, "Never place procedural code directly in an event." While I understand the value of the Template method, I'm not clear at all on the difference between placing code in an event or having the event method call a separate procedural method. Would you kindly elaborate on why you made that statement?

Many Thanks,
Ken Green

…and my reply

Ken,

Thank you for purchasing the book and the kind words.

Whether you are building the framework for yourself or others, I find that creating separate methods makes the framework more intuitive and therefore easier to use.

As I mentioned in the book, placing code in a separate method tends to 'document' the code. For example, placing code in the MouseEnter() event does not tell the reader exactly what is happening. Creating a separate method, HighlightCaption() for example, gives
the programmer a better understanding of what happens in the MouseEnter() event.

Separating the action from the event makes it more intuitive to call the event from elsewhere in the application. For example, you may find that you want to highlight captions when something happens on another form. While it is just as easy to call the MouseEnter() event from another form, it is certainly not as intuitive.

Placing procedural code directly in native FoxPro events is certainly faster. Frankly, I sometimes 'violate' this general rule in applications that I build. However, when developing a framework, you are creating a tool for creating applications. By their very nature, frameworks are complex. Anything you can do to make the framework more intuitive and easier to use increases the chance that you will enjoy using the framework and be more productive with it.

Ken Chazotte.