Release per April 5, 2022: InPlace v0.15.0

InPlace Version v0.15.0 delivers the following milestones in the project Practical Tools to Build the Context Web as supported by NLnet:

• A language for composing screens (Milestone T7).

This milestone is about describing a screen for a particular user in a context, in a model. In essence, a screen a is series of tabs where each tab is composed of widgets that can be arranged in rows and columns. Currently we have just two widgets: the form (for a functional role) and the table (for a relational or multi-role. Here is an example:

    user Tester filledBy sys:PerspectivesSystem$User
      indexed com:Tester
      perspective on TestRole
        props (Text, Bool, ADateTime, ANumber) verbs (Consult, SetPropertyValue)
        only (Remove, Create)
      perspective on TestTable
        defaults
      screen "Test screen"
        tab "Test"
          row
            column
              form TestRole
                props (Text, WeekDay) verbs (Consult)
                only (Create)
              table "MyTable" TestTable
                view Limited verbs (Consult)
                only (Remove)

Screens are generated client side from a datastructure that results from parsing source texts like the one above. When no screen has been modelled, the PDR generates a default screen layout consisting of a single widget on its own tab for each role that the user has a perspective on in the context.

The compiler checks the following constraints concerning a screen specification:

• The role that a widget is applied to, must exist.
• Widgets are for either functional or relational roles. The compiler checks whether their application fits the role they are applied to.
• The user role must have a perspective on the role that a widget is applied to.
• A view that is referred to, must exist and must be defined on the role that the widget is applied to.
• The properties that are referred to, must be available on the role that the widget is applied to and the user must have a perspective on them.
• The verbs that are referred to with regard to properties, must comply with the perspective the user has on the role that the widget is applied to.
• The role verbs that are referred to, must be in the perspective the user has on the role that the widget is applied to.

The verb- and property specification of a screen may only serve to further restrict the possibilities given by the perspective a user has on the role that underlies the widet.

There are now three sources of screens:

• default screens (as described above)
• modelled screens
• hand-crafted screens, built from ready-made React components using the library perspectives-react.

Major changes

• A language for composing screens.
• Refactoring of perspective serialization. State wasn't handled correctly in serialized perspectives. This has been corrected. As a consequence, the population of a table or a form will change as state of the subject, object or context changes (as modelled, of course).

Minor changes

• Default screens formerly were generated client side. With the advent of modelled screens, this has been brought into the PDR.
• Fixed a mistake where transitive closure of Aspects was not taken into consideration on looking up inverted queries, leading to missing updates, state triggers and synchronisation
• Perspectives with just automatic effects, notifications or user-triggered actions were not taken into account for synchronisation.
• Edge case for serialisation fixed: a query that ends on a binding step, without propert verbs.

Documentation

• Synchronization and state. The conditionality of perspectives on state affects synchronisation.

Updated documents:

• Reference of the Perspectives Language
• End user guide to InPlace
• Aspects require refinement of inverted queries. The use of Aspects requires us to rethink the notion of the web of context and role types.
• Synchronisation edge cases. An exploration of difficult cases of synchronisation.