Tom Moseley - Concepts in Template Writing

Posted September 1 1997

Printer-friendly version

"Code it the first time.... and if you are going to use it again, put it in a template." That should sound familiar, it is in the Clarion manual and you have probably heard it if you have been part of the Clarion community for more that a week. That sounds good eneough, but many long time Clarion coders have never read the templates and get along fine. Others get lost in the first few lines and would just rather put things in the embeds as they always have... or suffer the available functionality until 'one of the really smart ones'  writes a new template or makes an extensiion available. Depending on the work load, experience level and the function, that may be all you want to do. But as those who have tried it will tell you, there is another level of excitement available when you put code in that first embed that YOU placed in the template(s) because YOU wanted it.

Who better to lay out the appetizers for the template writing feast than Tom Moseley. For those of you who do not recognize the name, Tom was the author of the Clarion Windows templates up through version 2.00. Since that time Tom has gone on to found The Moseley Group and Clarion Online. Among other things, The Moseley Group produces and sells the DET Templates that show the rest of us why some of the text field hooks were built into the CW dictionary, plus some other acts of legerdemain that can save time, money and effort during code generation and maintenance.

Tom took the time during DEVCON '97 to treat his audience to a sampling of tasty tidbits to whet anyone's appetite for template productivity. Here's a sample of what was on the menu.

Tom cautioned the group that writing successful templates or template additions was all about understanding the time relationships. At what point in the code generation cycle was your template code going to be needed to accomplish the desired end point. The times we need to be concerned about are :

• PopulationTime -- putting prompts and fields on a template and/or when loading up the app.
• Design Time -- when either your user or you is working in the app gen.
• Generation Time -- well, you know --"Time to make the donuts!"
• Compile Time and Run time are just too late. That's when you find out how well you did.

With time in mind, Tom carried us on to some insights on symbols. Symbols are those key words proceeded by %'s that stand in for all the names we want to call things... that the templates can't know until... well, until we call them that; File names, and key names, and globals and so on. Tom reminded us that there are Single-Valued (like %Application) and Multi-Valued (%File, %Control) symbols and then pointed out that both of these may have dependencies... (FieldNames depend on FileNames). Tom then saved us all some sweat by telling us about FIX and FIND. Basically, they both set up the environment for a set of Symbols/Symbol dependents. The trick is, only use FIND with Files; if you use it with Procedures, your template code will be working in the wrong area of the APP tree... not good. Additionally, Tom pointed out that Symbols come in three varieties, Built-in's (in da box), User-defined (home made) and Prompts (hybrids of the first two, set by the template user.)

Tom explained one thing you may have wondered about in the templates. When there are Multi-Valued symbols like FileName the templates loop through them with a

#FOR %Symbol
  ...
#ENDFOR

syntax. Ah... ha, looks like C, heh. Well, it helped me.

Tom moved on to give us some hints on embeds. The hint here was to remember that they are passive. And I quote, "Like and old girl friend... they just sit around waiting to be called." The deal here is that the template writer has got be be sure to get the name right. Wrong name... won't be found, won't get called. So study up on the #AT code and get the spelling right.

Tom left us with some hard won advice...

1. Use small steps... just do one thing at a time and check the results
2. Write the prompts and get the interface right, THEN
3. Design your controls, THEN
4. Put in your ATSTART, the first section processed as generation of the procedure starts, THEN
5. Use AT(%GatherSymbols) and make sure you have all your values, THEN
6. Write the code for the EMBED points in AppGen and THEN
7. Transfer the code, one EMBED at a time to the template

Sounds like a recipe for success. Now, where did I put that Template Language Reference and that to do list.

Article comments

Post a comment

You must be logged on to post comments.