Hi Juergen,
to create a Person topic via REST:
curl -X POST -H 'Authorization: Basic YWRtaW46' -H 'Cookie:
dm4_workspace_id=2301' -H 'Content-Type: application/json' -d '{
type_uri: "dm4.contacts.person",
childs: {
dm4.contacts.person_name: {
dm4.contacts.first_name: "Lucy",
dm4.contacts.last_name: "Suchman"
},
dm4.contacts.email_address: [
"[email protected]",
"[email protected]"
],
dm4.contacts.phone_entry: [
{
type_uri: "dm4.contacts.phone_entry",
childs: {
dm4.contacts.phone_label: "ref_uri:dm4.contacts.mobile",
dm4.contacts.phone_number: "0177 123456789"
}
}
]
}
}' http://localhost:8080/core/topic
While not all the Person's child topics are set in this example (no Address for
example) this demonstrates some crucial aspects. You should be able to transfer
these to the other Person parts.
You create a Person by POSTing a topic JSON representation to /core/topic.
Note that the JSON is less verbose than the JSON you're GETing, e.g. you must
specify no "id", "uri", "assoc" properties, and no "value" property for
composite topics (as this is computed).
You see, when the child is modeled as cardinality "many" you have to specify an
JSON array, that is [ ... ]
Another important thing is when the child is modeled via Aggregation
Definition. In this case you have 2 options: a) create a NEW child, or b) refer
to an EXISTING child. This is relevant e.g. with the Phone Label. Here you want
refer to the existing phone label "mobile". You can do the referral by-ID or
by-URI. That is you must know the ID or the URI of the topic you want refer to.
You must prefix the value with "ref_id:" or "ref_uri:" respectively. For the
Phone Label you use by-URI because its easier (the Phone Label URIs are fixed
whereas the ID differ on each installation).
IMPORTANT: if you don't use one of these prefixes the other case applies:
you'll create a NEW child, that is you would CREATE another Phone Label
(additionally to the 5 existing ones).
So, potentially you have to deal with referral and these prefixes always when
Aggregation Definitions are involved in the underlying model. That applies e.g.
also to all the Address childs (Street, Postal Code, City, Country). All these
are defined via aggregation. So, when you actually want REUSE e.g. the City
topic "Berlin" for all the Berlin addresses, you must refer to that very Berlin
topic (as said, either by ID or by URI).
One more thing: when you specify the child topics in a JSON topic, you can
choose between 2 formats: 1) the "simplified" format, or 2) the "canonic"
format.
Simplified format:
childs: {
type.uri1: "my value",
type.uri2: "my value"
}
Canonic format:
childs: {
type.uri1: {
id: 1234.
uri: "my.uri",
type_uri: "type.uri"
value: "my value"
childs: {
...
}
},
type.uri2: {
...
}
}
That is with the simplified format you specify just the child topic's values.
That is sufficient e.g. when you want create a bunch of simple child topics
with just the (payload) values set.
In contrast when you want give the new childs topics not only the (payload)
values but dedicated URIs as well (or when when the childs are not simple but
composite) you have to choose the canonic format. Here you can specify complete
topic representations possibly with all of the 5 canonic topic properties (id,
uri, type_uri, value, childs).
In a topic JSON representation you are free to mix both formats, just like in
the Person example above.
Tell me if you need any more help.
Cheers,
Jörg
On Feb 18, 2015, at 17:31, Juergen Neumann wrote:
> Hi Jörg et al.,
>
> how do I get|write all data from or to an dm4.contacts.person instance,
> including multiple adresses and phone numbers. I did not yet manage to
> get the complete composite through the REST call.
>
> Can you help me please.
>
> Thx
>
> Juergen
>
> --
> devel mailing list
> [email protected]
> http://lists.deepamehta.de/mailman/listinfo/devel-lists.deepamehta.de
--
devel mailing list
[email protected]
http://lists.deepamehta.de/mailman/listinfo/devel-lists.deepamehta.de
