Dealing with server side generated data and forms

[joepio]

One of the things that Atomic Data enables, is rendering Forms for data that you've just encountered. The client will be able to fetch the Properties and Classes, and will be able to determine which HTML input fields should be rendered. However, some of these properties may not be editable. Some fields are generated by the server at Runtime, such as the members property in a Collection. This value is dependent on the filters being set in the Collection, or the query params that are being passed. The current implementation shows these fields

How to deal with this?

Add the generates property to classes, next to requires and recommends

So at this moment, Classes are responsible for generating most of the form. They define which properties are required and recommended. It therefore seems logical to also add a generates property, which tells the front-end that it doesn't need to show these fields in a form, because editing them doesn't makes sense.

However, this means that the class becomes harder to re-use in a context that has different considerations. (see next item for example).

Add a isGenerated property to Properties

Instead of making Classes responsible for providing this information, we could let Properties describe which item is generated.

However, this would mean that re-using a property becomes harder. Say we have two servers, and server 1 generates thefullName property, while server 2 has it stored as a literal, editable value. They would need to use different Properties, which would make their data harder to combine!