Still Refactoring

We’re down to 7 scenarios not completing, and it looks like the problems are in some of the transition management code. All of the tests for the Exhibit extension are passing with the new context system. The XML extension looks like it should pass as well as soon as the 7 get fixed.

I’ve added a new class: Fabulator::Action. This provides basic support for the common use cases where we gather a bit of information at compile time and then do something with it at run time. The class manages the compile time side of things. All you have to do to create a new action is declare your default namespace, a list of attributes you want to handle at compile time, and what you want to do at run time.

For example, from the Exhibit extension, we have the following for adding a value to the set of values we’re building for an item:

We still need to do a better job than the Fabulator::Exhibit::Actions::Lib.add_item_to_accumulator call if we ever want to support multi-threaded execution, but we’re getting there.

Some other examples (without the run time code):

Inherited attributes can be placed on any of the ancestor XML nodes as well as the current node. The closest attribute to the current node wins. This allows us to declare a global default Exhibit database and override it only when we need to. Static attributes are expected to be constant at compile time, so we don’t re-evaluate anything at run-time. Some attributes, such as the name of a view, are static. We try to avoid them if we can because they create inflexibility.

Published by


James is a software developer and self-published author. He received his B.S. in Math and Physics and his M.A. in English from Texas A&M University. After spending almost two decades in academia, he now works in the Washington, DC, start up world.