Templates 101 - It's About Time

by Tom Moseley

Published 1997-07-01    Printer-friendly version

Hi!

I wanted to start the column off on a sorta informal note. It's just the way I do things. This column, Templates 101, is a beginner's course in template programming. That's not to say it's a column that only beginners can learn from, it's just that the column is a concepts column. It teaches the concepts of template development, rather than getting into writing actual templates.

It's just that, you see, I teach template classes, and in the course of these classes I've found that there are certain concepts that aren't adequately understood, and that cause a great deal of consternation. It's with this in mind that I launch Templates 101 with my first installment, It's a matter of time.

What's time got to do with it?

I'm glad you asked. Time has everything to do with template programming. There are five distinct time periods that the template developer has to be concerned with:

• Population Time
• Design Time
• Generation Time
• Compile Time
• Run Time

You, the template developer, have to be aware of what happens in each time period. So, without further ado...

Population Time

This (obviously) is the first time that you need to know about. Population Time is the time when AppGen becomes aware of the population of a template. There are two distinct times when "Population Time" takes place:

• When you populate a template into AppGen - You know, you say "Insert a template" or you populate a control template.
• When AppGen loads your application into memory from disk. Whenever AppGen encounters a template, AppGen does its Population Time stuff.

During Population Time, the data declared in #LocalData, #ModuleData, and #GlobalData sections is added to the appropriate section of data, if the variables aren't present. This is why, if you change the data properties of a template field, they persist, but if you delete a field it reappears magically the next time you load your application.

Population Time is the only time that these data sections are processed. This is very important because NO template symbols can be accessed at Population Time. This is why you cannot have a template populate fields with template instance specific names.

Design Time

Design Time is your "User Interface" time with the template user. Design Time is when your user is filling prompts and configuring controls. Some template developers think that Design Time is the first "time" that the template has access to. As we've already seen, this isn't so.

Now, it's important that you notice that the two actions that are important at design time are prompt filling and control configuration, not just prompt filling. You can glean a whole lot of information from the information your user provides in control configuration and from the dictionary. From templates I've seen, it seems as if many novice template writers use about 50% too many prompts, forgetting to look at what the user has said about a control at design time.

With one exception, during Design Time you can't access any user-defined template symbols. You can, however, access most built-in symbols at Design Time. The exception is the use of #PREPARE in a prompt set. We won't address the #PREPARE section in this article.

Generation Time

This is the "time" that template writers really shine. During Generation Time, control of your application has been turned over to the #APPLICATION template, and the templates are doing their thing.

Generation Time is primarily important as a separate time because how your template writes code controls what happens during the next two time periods.

Compile Time and Run Time

Yep, you guessed it. Compile Time is when the compiler is running your code through the mill and Run Time is when your program's running. You're probably wondering why the distinction is so important. Well, I'll tell you.

You, the template writer, have a decision to make about when your code does its stuff.

For example, lets say you're writing a control template that populates an object into a procedure. You can declare the object, which causes the memory and structures to be allocated at Compile Time. As an alternative, you can instantiate the object at Run Time, which causes the memory and structures to be allocated at Run Time.

Each time has its advantages and disadvantages. Things done at Compile Time tend to run slightly quicker since the memory is allocated when the procedure is run. The primary disadvantage of Compile Time code is that it's less flexible, in that you can't have the end-user (not the template user) add any objects at Run Time. The opposite is true from the other direction.

So when do you make your code do things at either time? If you need to create things at runtime, or if the sheer overhead of many Compile Time structures is excessive, use Run Time code. Otherwise, use Compile Time.

Sheer Overhead? Yep, that's what I said. The Clarion for Window Print Preview, for example, does most of its thing at Run Time. If I'd have written the code for every control separately, or tried to design a window with the two or threel hundred controls necessary for the print preview to work, debugging the code generation would have been a bear. By doing the work at Run Time, the overhead of the templates was diminished greatly, dubugging became manageable, and the code compiled into a nice tight package.

Next Time

That wraps up the first Template 101 class. Next time, we'll talk about built-in template symbols. I'll temll you the really impotant ones and how to use them. We'll also talk about the template statements used to access these symbols.

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942