Re: the necessity of describing responses in-band

2015-10-07 21:43 GMT+02:00 Karol Szczepański <karol.szczepanski@gmail.com>:

> Well, it was all about returned values. For a UI you have to know whether
> the returned is either a multi or single values. This was reflected in the
> UI either with a grid or key-value pair fields.

Makes sense.

> As for custom extensions, we had to cover (in short):
> - C# dictionary / Java map data structures (formally it's key-value pairs
> collection, but key is unique) - this is actually not covered natively by
> RDF itself, we hade our own structure here

What did this custom structure look like? How did you express it and
consequently map it to C# and Java? Do you have code examples? I feel
like this is something that would be useful to have in a public
repository on https://github.com/HydraCG/.

> - multi-values for grid based views
> - single-values for key-value pair views
> - named individuals (i.e. enumerated values) for dropdowns

Examples on how each of these looks like in both your custom Hydra
extensions and how it maps to C# and Java would be very valuable.

> - other than RDF expected/returned values (i.e. API allowed to have an URI
> for resource's label accepting ... string - this doesn't fit to hydra's
> class expectation)

So Hydra needs to support simple types, then, yes?

> - property value change event (we had to know whether the value changed to
> send back a CQRS command to the server).

This was pushed from the server? If so, how? And if not, could you
please elaborate?

> From all of these sorting was the easiest - this required rdf lists which
> are the simplest to identify as there is a separate class for that!

Great. I hope you can provide more detail. :)

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»

Received on Wednesday, 7 October 2015 21:37:51 UTC