this._productViewsPromise = backend.fetchAll({
ofType: new SpineWebClient.Type(
ProductView,
new SpineWebClient.TypeUrl('type.teamdev.com/teamdev.licensing.q.product.ProductView')
)
}).atOnce();
That is, besides the ProductView entity type, we have to provide its full type name with type URL prefix, and create a nested structure of objects from these values.
sendCommand invocation looks like this (given that we already have a constructed instance of command message, e.g. createSingleDevLicenseCommand here):
backend.sendCommand(new SpineWebClient.TypedMessage(
createSingleDevLicenseCommand,
new SpineWebClient.Type(CreateSingleDevLicense,
new SpineWebClient.TypeUrl(
'type.teamdev.com/teamdev.licensing.c.singledev.CreateSingleDevLicense'
)
)
), ...commandCallbacks);
Same problems as above, but somewhat more complex.
The way this is currently worked around
We currently try to solve this on the side of License Server application by introducing utilities (1, 2) for creating these structures of instances, but we still need to provide additional data that could ideally be not needed (type names, type URL prefixes).
The preferred solution
This request is to make such usages as simple as possible. Here's what the above examples could ideally be like:
Problems in the current API
Specifying entity/message types in spine-web-client's public API methods is currently very complicated.
Usage examples of the current API:
fetchAll
invocation looks like this:That is, besides the
ProductView
entity type, we have to provide its full type name with type URL prefix, and create a nested structure of objects from these values.sendCommand
invocation looks like this (given that we already have a constructed instance of command message, e.g.createSingleDevLicenseCommand
here):Same problems as above, but somewhat more complex.
The way this is currently worked around
We currently try to solve this on the side of License Server application by introducing utilities (1, 2) for creating these structures of instances, but we still need to provide additional data that could ideally be not needed (type names, type URL prefixes).
The preferred solution
This request is to make such usages as simple as possible. Here's what the above examples could ideally be like:
and for sending a command: