In general, you should do all data manipulation for code generation at capture time; not at parsing time. At capture time, all of the original objects are easily available. The alternative is to generate intermediate tokens and write parsing code for them. It is easier just to generate the correct code to begin with, especially if attributes of several objects need to be taken into consideration to make a decision (for example, peer schemas and dynamic controls). It also makes the rrmsg.log much easier to deal with.
As the capture method is necessarily complex, take care to keep it clean and tidy. Where practical, you should transfer larger chunks of code to additional methods, to keep the size of the capture method under control. However, this needs to be balanced against creating a large number of methods in the class, which would also be unwieldy.
To help avoid a naming conflict when ATCG schemas are loaded under an application schema, some naming conventions need to be strictly adhered to.
In the AtcgGeneratorSchema schema, all class names other than those based on the schema name (that is, app and global) must begin with Atcg.
All methods and properties on app, global, JadeScript, and RootSchema classes must begin with atcg.
This also applies to all primitive methods, external methods and external functions. It does not apply to method reimplementations on app such as app.msgBox.
In the AtcgTestCodeSchema schema, the same rules as those for AtcgGeneratorSchema apply for classes and methods that "belong" to ATCG.
For methods that are designed to be modified for use with different databases (for example, app.atcgGetControlOptions), there is a second copy of the method with the suffix Sample; for example, app.atcgGetControlOptionsSample.