14.4.1. Local and remote
In the simplest case, a user role has a CreateAndFill perspective on a local context role. It allows them to add a role instance (bound to a context instance) in the context that they belong to.
However, with the existence of Calculated roles, a user role has access to ‘remote’ roles, too. As long as there is a path leading from the user role’s context to a role, the modeller can grant a perspective on that role. And this perspective may include the verb CreateAndBindContext.
However, in order to create a context somewhere else, that ‘somewhere else’ must be well specified. Let’s first examine the way the modeller instructs the system to do so, on behalf of some user.
We’re not just talking about creating, but also filling; in the following, I will not tediously repeat ‘create and fill’ but just write ‘create’, meaning ‘create and fill a new context role’.]
14.4.1.1. Create a remote context automatically on behalf of a user
First, we create a Calculated role that consists of a remote context role (without losing generality, we can assume for the sake of simplicity that roles A and C are functional):
context: Remote = A >> binding >> context >> C
Instances of Remote actually are instances of C, in some other context.
in state <SomeState>
on entry
do for User
create context X bound to C in A >> binding >> context
This causes a new instance of role C to be created in the context identified by A >> binding >> context, on entering state <SomeState> (for an otherwise unspecified resource). It is filled by the external role of a new instance of context type X.
Of interest is the clause in create context X bound to C in create context X bound to C in A >> binding >> context. It says in what context instance the new context role is created. Notice that it equals the definition of Remote, except for the last step. So the clause identifies a particular context instance (remember we created Remote to be a functional Calculated role) and creates a new context role in that instance.
Obviously, creating a context locally is simply:
create context X bound to C
We just leave out the in clause to create in the local context. The general syntax is:
create context ContextType bound to RoleType in <contextExpression>
14.4.1.2. Create a context, fill an existing role
A variant of the use case given in the previous paragraph would be the situation where we already have a role instance to fill the new context instance with. We then use a variant of the operator:
create context_ ContextType bound to <roleExpression>
Notice that
-
we do not need to provide a context: the role instances selected have a context;
-
we can never create an unbound context (see below for a definition) in this way.
14.4.1.3. How an end user creates contexts
Can an end user create a context remotely, too? Let’s explore what that would mean. But before we do so, I’ll show how an end user creates a context locally.
Through some user interface – let’s assume it to be a GUI – the user has navigated to some context instance. In that context instance they play a particular role and with that role comes a screen, providing perspectives on the context instance. Returning to our example, we assume the context to be the one that has context role C. Now in order to create a new context in C, the end user instructs the core system, through its API, to execute create context x bound to c on the current context, with type X for role C. That’s it.
In contrast, assume the end users’ current context is the one that holds the role Remote. Now, the context holding role C is remote. For the end user to create a new context instance in that remote context, he has to identify that remote context in some way. This means that his GUI must offer him a means to do so.
That may be quite easy: for example, just consider a conventional order-detail screen, where both order and detail are represented as contexts. The end user can simply point to a detail and (for example) push a button in it to create a new context in it (say, a delivery sub context; so C – a role in the detail context - is bound to a new delivery context). The core API receives, along with the instruction create context, the (remote) context representing an order detail and the role type (delivery) to create a new instance in.
14.4.1.4. Non-functional Calculated roles
What if role C were not functional? The in clause in the bot’s rule would now potentially identify many contexts. If not modified, the rule would create new contexts and fill all of them. It is up to the modeller to decide if that is desired behaviour. To avoid it, he might, for example, filter away from the retrieved contexts those that already have an instance of B.