Right another set of requirements now that the structure of the template is settled upon. How to do it algorithmically.
What do we need?
Speed – we want it to be as efficient as possible at the quickest speed possible.
Size – we want to handle templates that may be extremely large, I am thinking ebooks or other media later.
Flexibility – we want to be able to ensure that all inter-related functions within a template are dealt with. This means they should always all get resolved fully but only when they are likely to be needed. If a function makes a call to a data warehouse or database then it should only happen if that part of the template will actually get spun. Otherwise you will get unnecessary calls.
Simple passing through the template and resolving each of the delimiters is the very simplest method, but with spins within spins we need either multiple passes or recurse. My first impression was to go the easiest route and even though it would be quicker to create a recursive call into the template it may not be known which parts of the spun documents are known. That method was certainly adequate for the ArticleBot kind of processing that existed earlier but there is another problem. Speed will be important really only when producing loads of output so parsing them first seems to be the best idea.
So the first pass into the template from beginning to end will be to pull out the codes or spun items into variables. These can hang around and get used when the article is being spun.