27.1. Not an Aspect pattern

Unfortunately we cannot yet turn this pattern into reusable aspect role and contexts. This is because it crucially depends on the indexed name of the App context. In the future, we may strengthen type level queries up to the point we can actually make the aspect approach work. It would require the following steps:

  • from the external role of the incoming case, move to the type level by getting its type (ClientCase$External);

  • on the type level, move to the role type that is filled by it (ClientCases);

  • on the type level, move to its context type (PsychoTherapy);

  • get its indexed name (ps:PsychoTherapyApp);

  • finally, from that identifier, get the (local) instance of PsychoTherapyApp

All this comes in place of the step ps:PsychoTherapyApp. We might make it a little more readable by including the indexed app as a calculated context in ClientCase:

    context TheApp = contextType >> extern >> binder TheContextRole >> context >> indexedName >> contextinstance

(notice that because this query starts at the context instance rather than the external role, we have to include that step). In this example, the query steps extern, binder and context are overloaded for the type level. contextType already exists. indexedName does exist, but should be overloaded for the type level.


1. If no authoring role is provided by the API caller, we take it to be the System User.