Runtime

Architecture overview is the static map: layers and repositories. This page is about what happens while Openflexo runs — start-up, the FML processing chain, executing a behaviour, and applying a model change.

Service manager start-up

Services are registered one after the other, in a fixed order: the base services (localization, editing, tasks, resources, projects), then the resource centers found on the classpath, then the technology adapters — registered, but not yet activated — and the VirtualModel library, which activates the FML adapter. The other services and the application editor follow.

Technology adapters are activated on demand. Once activated, an adapter scans every resource center for the resources it knows how to read (see Resources and their life cycle).

The FML processing chain

Loading a .fml file runs it through a parser and then a semantic analysis pass, which resolves imports and types once every compilation unit's dependencies are parsed, giving the in-memory FML model. Saving reverses it: a pretty print step turns the model back into .fml text.

A compilation unit that fails to parse is not the same as one that fails validation: a ParserException leaves an empty model behind, and that empty model then reports zero validation errors. A clean validation report is not on its own proof that a .fml file parsed.

FML execution engine

Calling a behaviour builds a FlexoBehaviourAction, which runs the behaviour's control graph and gives back the returned value. Firing an event goes through FMLRunTimeEngine: it registers every VirtualModelInstance when its resource is created or loaded, and delivers the event to whatever listens for it on that instance. The engine runs in the calling thread.

The action layer

Every change to a model is packaged as an action: a FlexoActionFactory builds a FlexoAction and says whether it is currently enabled, and a FlexoEditor performs it and records the undo. A FlexoBehaviourAction (above) is itself a FlexoAction — running a behaviour goes through this same layer. In the interactive editor, performing an action starts an undo transaction, asks for the action's parameters, executes it, then ends the transaction. The headless editor only checks the factory, then executes: it has no undo to record.