volks73
commented
4 years ago See this comment in #7. I don't think hooks are going to happen as originally envisioned with this v2 architecture coming into play. So, the logging for debugging should probably be handled "natively" by the new v2 architecture instead of using hooks.
In this vane, I would add a FIFO queue to each class, Compiler, Lexer, Parser, and Renderer, called "Stack Trace", "Trace", or "Trace Log" (probably this last one). Each class would enqueue a string as a log statement. When the Shutdown.vi for each class is executed, the Stack Trace queue to flushed and all elements (array of strings) are returned as an output to the VI. This can be appended to a parent class's Trace queue, written to a file as a series of lines, concatenated into a big string, added to a listbox control, etc. A protected "Log.vi" would be added to each class that could be overridden by sub-classes if desired and/or provide access to the logging as well.
Ah, but the true OOP way of doing this might be to create a "Log" class that contains the queue and the Compiler, Lexer, Parser, and Renderer classes inherit from this class.
Note, the Initialize.vi would create the queue and the Shutdown.vi would flush and release the queue.
It would be nice to have log-like statements "fired" while compiling a template. The statements could be sent to a log file or a "console" (string control). This would be useful when debugging a template. The statements would include the tokens identified, the data found for rendering, the node currently being rendered, etc. Basically, show the stack trace for compiling.
I have run into a couple of issues when using the toolkit that took a while to resolve because it was difficult to follow the recursion that is inherent in the compiler implementation. Having a stack trace would have nearly immediately identified the causes.