When shared workflow definition are used, a different management of object specific code is necessary, since one definition seves for many objects, and it is not freshly created per object. Therefore, a new concept is introduced for workflow definitions, named "object-specifc" Instead of writing in a workflow definition
where the object-specific is evaluated once per request for every involved workflow instance in the context of the object (a [self] in this block refers to the object).
In case a [my object] is encountered and sharedWorkflowDefinition is activated, a warning is produced and the code falls back to old-style shared workflow definitions.
Background: so far, xowf stored workflow definitions in the workflow context, which is generated for every instantiated workflow instance due to the needs of the State Pattern. While the old approach works perfectly fine, when pre request only one or a few workflow instances are created, but is inefficient, when e.g. 100 or more instances of the workflow definition are created.
Now, the instances can share the definition, which is shared based on the revision_id of the workflow FormPage.
OLD scenario: - the wf_definition was part of the context (no distinction) - navigation from wf_ctx (and wf_definition) to object was possible via "info parent"
NEW scenario: - the wf_definition is separate - one wf_definition can be used for multiple wf_ctx
- new methods are required instead of "info parent" to navigate between these cooperating objects
The navigation from a WorkflowConstruct (e.g. State) to the wf_ctx is slow and fragile if not following usual programming conventions and should e avoided (the methods of these constructs have the obj passed in, so this path should not be necessary in most situations)
- as long the contents of the wf_container is constant, it can be shared in the per-thread cache.
For now, the new feature is turned off by default via variable ::xowf::sharedWorkflowDefinition, but this will change in the future.