Possible change to the way proto-persistent objects are handled.

[richardpawson]

For RO 2.0, I think it would be worth considering changing the approach to proto-persistent objects - bringing them more into line with addressable view models (which should also be brought properly into the next release of the spec, whether 1.1 or 2.0).

I am suggesting that even proto-persistent objects would be properly addressable. One possibility would be to give them a clearly distinct form of Id e.g.:

objects/customers/transient

or even

objects/customers/0 (since persistent integer Ids typically start from 1)

N.B. there is no need to distinguish two different transient instances.

Arguably, this is not then a spec. issue - it is up to the implementation to determine how to distinguish a persistent from a proto-persistent object. However there would still need to be:

• A hint to the UI that the object is proto-persistent (e.g. so it is then rendered straight into 'edit mode')
• A mechanism for persisting the proto-persistent object

Arguably, the existence of a 'persist' link could serve both purposes. Upon calling this link, an object of the same type but with a real (persistent) Id would be returned and it would have an update link rather than a persist link.

This just means changing the spec to say that an object representation may have a 'persist' link OR an 'update' link - or neither (for a non-addressable view model - not encouraged), but never both.

[richardpawson]

I wrote " (for a non-addressable view model - not encouraged)". But thinking on this, if we were to get rid of (non-addressable) proto-persistent objects, we should get rid of non-addressable view models also, in the same way!

[richardpawson]

Just for clarification, the changes I am proposing (or thinking of proposing) are:

1. That the domain object representation always has an Id, even for a proto-persistent object or view model, where the Id may be a 'reserved' Id recognised by the implementation (but not dictated by the spec) e.g. '0' or 'transient'. (Could even be 'null' as an explicilty recognised Id ?)
2. It follows that the object representation then can always have a Self link.
3. That the domain object representation may have a persist link or an update link, but not both. (it could have neither, if it was an unmodifiable object). The existence of a persist link implies that the object is currently proto-persistent. On invoking the persist link, the returned object representation will typically have a different Id.
4. The persist link is now to the URL for the transient object e.g. ~objects/customer/0 - not to the 'objects of type' resource (e.g. ~/objects/customer ) - which would become redundant.