10.3.2. Contextualising a Perspective
We work with an example, taken from model:BodiesWithAccounts:
case Body
user Test
property UserName (String)
user Admin filledBy sys:PerspectivesSystem$User
aspect bwa:WithCredentials
perspective on Accounts
only (Create, Fill, CreateAndFill, Remove)
props (UserName, Voornaam, Achternaam) verbs (SetPropertyValue, Consult)
user Accounts (unlinked, relational) filledBy sys:PerspectivesSystem$User
The user roles in this model fragment are used as Aspects in another model, model:CouchdbManagement:
case CouchdbServer
aspect acc:Body
user Admin filledBy CouchdbManagementApp$Manager
aspect acc:Body$Admin
perspective on CouchdbServer$Accounts
props (ToBeRemoved) verbs (Consult, SetPropertyValue)
user Accounts (unlinked, relational) filledBy sys:PerspectivesSystem$User
aspect acc:Body$Accounts
Notice the relations between the latter model and the former:
-
CouchdbServerhas Body as Aspect; -
CouchdbServer$Adminhas Body$Admin as Aspect; -
CouchdbServer$Accountshas Body$Accounts as Aspect; -
Both Admin roles have a perspective on the Accounts role in their context.
10.3.2.1. What we want
Clearly, we want that CouchdbServer$Admin can apply Body$Admin’s facets of the perspective on Body$Accounts to CouchdbServer$Accounts. Specifically, we expect CouchdbServer$Admin to be able to create an instance of CouchdbServer$Accounts in virtue of the perspective of its aspect Body$Accounts.
But we also expect that the verbs applicable to the property ToBeRemoved are available to CouchdbServer$Accounts.
In other words, we want to ‘add’ both perspectives in such a way that the resulting perspective:
-
grants access to the union of the properties of both;
-
allows, per property, the union of the propertyverbs allowed by each perspective individually;
-
allows the union of the roleverbs allowed to each perspective individually.
To add two perspectives is conditional on the relation between their objects: we may only add an Aspect perspective to another perspective if the latter’s object is a specialization of the former’s object.
Compile time contextualisation
For roles that are added as is to a context, we’d have to contextualise
-
their calculation (if any): this would be query contextualisation and the paragraphs below will show we will apply run time contextualisation to queries. Consequently, no specific action is required for the compile time contextualisation of the calculation of roles.
-
Their perspective object. As these are queries as well, this falls in the same case as calculations. No action required.
-
Their Actions (actions with an object). As the relevant paragraph will show, Actions will be contextualised in run time.
In short: nothing needs to be done to contextualise a role that is added as is to a context.
For roles that are added as an aspect to a role, things are different. First of all, we have to distinguish two cases:
-
An aspect adds a perspective on an object that the specialised user role does not have a perspective on. In this case, the perspective is added as is to the specialised role (is simply copied).
-
The specialised user role already has a perspective on a local object role, that turns out to be a specialisation of the object of the aspect user role.
In the second case, we have to adapt the perspective of the specialised user role, but only with respect to its
-
role verbs,
-
property verbs.
Role and property verbs are additive over aspects: a verb applicable according to an aspect or the specialised role is applicable to the specialised role.
Where perspectives are used, does contextualization matter?
Synchronization. The query that is the object of the perspective, is inverted in order to find user roles that should be informed when a change affects the outcome of that object query. Obviously, the query must be contextualized if it is taken from an aspect to a special context. However, because queries are contextualized run time, no further action is required for synchronization.
Authorization. A Delta is only accepted if the author of the change it describes, does have a perspective that authorizes him to do so. Contextualisation of aspect perspectives is important for this process, as the required authority may derive from an aspect. Compile time contextualization as described above will do the trick neatly.
Screens generation. Obviously, the perspectives contributed by aspect user roles to a user for whom we request a screen giving access to a context, cannot be missed. The mixed strategy contextualization of perspectives described above will take care of this.