Our shared front and back end classes continued to develop on day 4, here represented by Greg A and Ned discussing workflow definitions. This resulted in new shared classes for the overall set of fields available to the forms in the referral process, as well as the workflow that connects those forms, and updates to the detail of the form definitions themselves. Previously we had been working with only a single form, so this was great progress.
Client-side
Greg H worked on allowing elements to be defined as visible or invisible based on certain rules, and similarly for enabled and disabled. He also integrated the new shared classes and prepared the client-side to communicate with the server’s API based on a rough interface agreed with Andrew.
Ned continued customising the front end components to use the rules Greg H was creating so the UI reflects them correctly. He completed work on representing mandatory fields and started looking at showing different UI for text fields based on whether there was a rule that restricted the field’s length.
Server-side
Andrew completed the EventFlow “read store” (storing a cache of the system’s records to avoid needing to build those records from their history of events every time they are needed) using an in-memory cache.
Andrew also switched the web API project to ASP.NET Core 2.2 (previously it had been a preview of 3.0) due to compatibility issues with the latest stable Entity Framework release, which is required by EventFlow. Having done that he began work on the back-end to the API, for responding to GET/POST requests from the client.
Meanwhile, Julian continued his struggle with getting an EventFlow project working with Cosmos db. It turned out not to be possible to connect via Entity Framework using Cosmos’ SQL API because that relies on an identity column in the database, which is a concept Cosmos does not support. He began looking into using the Cosmos Mongo API instead.