Jackson allows Polymorphic Deserialization: http://wiki.fasterxml.com/JacksonPolymorphicDeserialization
Specifically, I am trying to use Global default typing with:
objectMapper.enableDefaultTyping();
Documentation specifies that request
..is included, using default inclusion mechanism (additional wrapper
array in JSON).
but I do not understand what exactly that means. I am not sure how to actually form the JSON request that specifies the subtype being sent. I tried the following three requests with no success so far:
{
"com.package.MySubType" : {
"name": "someName"
}
}
[
"com.package.MySubType",
{
"name": "someName"
}
]
{
"#type" : "MySubType",
"name": "someName"
}
I am checking for instance type using instanceof and it always fails.
Found my answer here: https://groups.google.com/forum/#!topic/jackson-user/nhZAn4TSHG4
[ "com.foobar.MyType", { "property1" : 2, "property2" : "foo" } }
Altho I decided to go the property route on the end because it seems more logical.
Related
This issue is a bit tricky to describe so bear with me and please ask questions if I am missing anything...
Say you have a json object that defines a list of features, each feature has a the same three properties but has a property that has an entirely different structure. For example:
{
features: [
{
id: "feature-a",
enabled: true,
configurationData: {
featureAConfigPropertyA: {
somePrperty: "whatever",
anotherProperty: true
},
featureAConfigPropertyB: "some string"
}
},
{
id: "feature-b",
enabled: true,
configurationData: {
featureBConfigArrayPropertyA: ["some string"],
featureBConfigPropertyB: [
{
"id": "some string",
"name": "some string",
"description": "some string",
"enabled": true
}
]
}
}
]
}
The actual structure of each feature is irrelevant. I am just trying to express this via json schema whereby the structure of configurationData for each feature is dependent on or dictated by the feature id value of its parent.
EDIT: I guess technically it doesnt need to be dependent on so long as either structure of configurationData is valid schema for that property on the feature schema itself. Also, the types in configurationData arent arbitrary, they would always be one of the two types for a given feature in this example.
This however needs to be structured in a way that can be expressed via Formly as I am using this to generate forms. In this case it would be an array of ObjectFieldTypes, one for feature a and one for feature b, which would enumerate the three properties and provide Input field types, until it got to configurationData at which point it would use an ObjectFieldType again, which would now be different for each field type.
The issue here is that 1) I'm not sure how to express this in json schema and 2) I can't use things like patternProperties with formly because the properties have to be explicitly defined in the json schema in order for formly to render the field types for each property. Although patternProperties would technically be valid schema in this case, if the schema doesn't define those properties, then the model in the valueChanges observable on the FormGroup just excludes them entirely. So I would end up with:
{
features:[
{
id: "feature-a",
enabled: true,
configurationData: { }
},
{
id: "feature-b",
enabled: true,
configurationData: { }
}
]
}
I have tried the if then else construct, but I cant tell if the schema is wrong or if formly just doesn't support this. I made a stack blitz for this below:
https://stackblitz.com/edit/angular-g45ydm?file=src%2Fassets%2Fjson-schema%2Fif_then.json
I've been wondering for some days what kind of scheme would be more appropriate to use a data list in json in a web application.
I'm developing a REST Web Application, and im using Angular for front end, i should order, filter and print these data list also in xml ...
For you what scheme is better and why?
1) {
"datas": [
{ "first":"","second":""},
{ "first":"","second":""},
{ "first":"","second":""}
]
}
2) {
"datas": [{
"data": { "first":"","second":""},
"data": { "first":"","second":""},
"data": { "first":"","second":""}
}]
}
3) [
{ "first":"","second":""},
{ "first":"","second":""},
{ "first":"","second":""}
]
Thanks so much.
The first and third notations are quite similar because the third notation is included in your first.
So the question is "Should I return my datas as an array or should I return an object with a property that contain the array ?
It will depend on either you want to have more information alongside your datas or not.
For exemple, if your API might return an error, you will want to manage it from the front end.
In case of error, the JSON will looks like this :
{
"datas": null,
"error": "An error occured because of some reasons..."
}
At the opposite, if everything goes well and your API actually return the results, it will looks like this :
{
"datas": [
{ "first":"","second":""},
{ "first":"","second":""},
{ "first":"","second":""}
],
"error": null
}
Then your front end can use the error property to manage errors sent from the API.
var result = getDatas(); // Load datas from the API
if(result.error){
// Handle the error, display a message to the user, ...
} else {
doSomething(result.datas); // Use your datas
}
If you don't need to have extra properties like error then you can stick with the third schema.
The second notation is invalid. The datas array will contain only one object which will have one property named data. In this case data is a property that is defined multiple times so the object in the array will contain only the last occurence:
var result = {
"datas": [{
"data": { "first":"a","second":"b"},
"data": { "first":"c","second":"d"},
"data": { "first":"e","second":"f"}
}]
}
console.log("Content of result.datas[0].data : ")
console.log(result.datas[0].data)
Obviously the first option would be easy to use. Once you will access datas it'll give you an array. Any operation (filter, sort, print) on that array will be easy in comparison to anything else. Everywhere you just need to pass datas not datas.data.
i am sending an Array list from Producer and i am expecting to read the same arraylist at the consumer and persist into Database.
Instead of me getting the the Object i am getting and json wrapped inside the Object,which i am not able to understand why.
Below is representation of different objects.
Expexcting:
user is [Users [id=1, name=Prashantrh, nm=com.example.demo.Name#2b65d9e7]]
Pickied up at consumer side as:
[
[
{
"dmetaD":{
"id":2315,
"embedded":true,
"size":123,
"comment":"raghu",
"name":"string",
"type":"pdf",
"creationTime":"2018-05-15T20:47:48.161",
"creatorId":15001,
"creator":{
"id":15001,
"shortId":"MARC6GR",
"firstName":"V15001",
"lastName":"N15001",
"emailPref":true,
"departmentName":"RD/FNT",
"inventoryType":"P",
"langPref":"DE",
"email":"V15001.N15001#d.com"
}
},
"dCont":{
"data":"abc"
}
},
{
"dmetaD":{
"id":2316,
"embedded":true,
"size":123,
"comment":"raghu",
"name":"string",
"type":"pdf",
"creationTime":"2018-05-15T20:47:48.163",
"creatorId":15001,
"creator":{
"id":15001,
"shortId":"MARC6GR",
"firstName":"V15001",
"lastName":"N15001",
"emailPref":true,
"departmentName":"RD/FNT",
"inventoryType":"P",
"langPref":"DE",
"email":"V15001.N15001#d.com"
}
},
"dCont":{
"data":"def"
}
}
]
]
First, please provide more details as to what version of Spring Cloud Stream you are using.
That said, I am going to assume for now that you are using 2.0.0.RELEASE which means the content type of the message defaults to application/json.
I'm consuming the JSON from swagger, and when I get to the responses I get a bunch of variables that are the response codes, aka numbers. The relevant section of the JSON is below.
"responses": {
"200": {
"description": "OK"
},
"404": {
"description": "not found"
},
"503": {
"description": "Problem with external dependency"
}
}
How do I deserialize this into a Typescript object or should I use a service to consume this and process it before handing something more manageable to Typescript? My current idea is to handle it in javascript, then spit something back that is easier to consume in typescript; but before diving down that rabbit hole (ok, not quite that bad, I can see the bottom) I figured that I'd see if there is a better solution.
TypeScript only exists at compile-time. At run-time everything is plain old JavaScript.
As (de)serialization happens at run-time you would be deserializing it in to a JavaScript object, but I assume you mean "Is it possible to create a TypeScript type definition that describes this incoming object?".
Also, the property names aren't numbers, they're strings that happen to contain numbers. This is an important distinction when creating a type definition as a string and a number are two different types.
The first step is to define the Response objects:
interface IResponse {
description: string;
}
Then, there are two approaches that can be taken for defining the Responses object. The first can be used if the property names are known in advance, the second can be used in a more generic fashion to support any property names of a given type.
Known Names
interface IKnownResponses {
"200": IResponse;
"300"?: IResponse;
"400": IResponse;
}
This defines an interface that must have properties called "200" and "400", and can optionally have a property called "300".
"300" is optional (search for the "Optional Properties" title) as it's property definition has a ? in it.
Dynamic Names
interface IDynamicResponses {
[responseCode: string]: IResponse;
}
This interface says that any string can be used as a key/property name, but that the property must contain an IResponse.
This is an indexer definition (look for the section titled "Indexable Types").
Example
These approaches can be seen working in the following example code:
interface IResponse {
description: string;
}
interface IKnownResponses {
"200": IResponse;
"300"?: IResponse;
"400": IResponse;
}
interface IDynamicResponses {
[responseCode: string]: IResponse;
}
let knownResponses: IKnownResponses = {
"200": {
description: "foo"
},
"400": {
description: "bar"
}
};
let dynamicResponses: IDynamicResponses = {
"200": {
description: "foo"
},
"400": {
description: "bar"
},
"401": {
description: "baz"
}
};
console.log(staticResponses["200"].description);
console.log(knownResponses["401"].description);
https://jsfiddle.net/L8dpomL8/3/
Unfortunately JSFiddle isn't a very good TypeScript IDE so it's hard to show the type information being used, but if you take this code and put it in your preferred IDE you should be able to experiment with it and figure out where the typings help you, and where they fail.
I'm having trouble properly formatting one particular soap parameter using the node-soap module for node.js as a client, to a 3rd-party SOAP service.
The client.describe() for this method says this particular input should be in the shape of:
params: { 'param[]': {} }
I have tried a bunch of different JSON notations to try to fit my data to that shape.
Examples of formats that do NOT work:
"params": { "param": [ {"myParameterName": "myParameterValue"} ] }
"params": [ "param": { "name": "myParameterName", "_": "myParameterValue"} ]
"params": { "param" : [ {"name": "myParameterName", "_": "myParameterValue"} ] }
"params": { "param[]": {"myParameterName": "myParameterValue" } }
"params": { "param[myParameterName]": {"_": "myParameterValue" } }
I must be overlooking something, and I suspect I'm going to feel like Captain Obvious when some nice person points out what I'm doing wrong.
Here is what DOES work, using other soap clients, and how they handle the "named parameter with a value"
soapUI for this method successfully accepts this particular input via XML in the shape of:
<ns:params>
<ns:param name="myParameterName">myParameterValue</ns:param>
</ns:params>
Also, using PHP, I can successfully make the call by creating a stdClass of arrays like so:
$parms = new stdClass;
$parms->param = array(
array(
"name"=>"myParameterName","_"=>"myParameterValue"
)
);
and then eventually passing
'params' => $parms
to the PHP soap client
Many thanks!
To get a better look at what XML was being generated by node-soap, I added a console.log(message) statement to the node_modules/soap/lib/client.js after the object-to-XML encoding. I then began experimenting with various JSON structures to figure out empirically how they were mapping to XML structures.
I found a JSON structure for node-soap to generate the XML in my 3rd-party's required named-parameter-with-value format. I was completely unaware of the "$value" special keyword. Looks like this may have been added in the 0.4.6 release from mid-June 2014. See the change history
"params": [
{
"param": {
"attributes": {
"name": "myParameterName"
},
$value: "myParameterValue"
}
}
]
(note the outer array, which gives me the luxury of specifying multiple "param" entries, which is sometimes needed by this particular 3rd-party API)
generates this XML:
<tns:params>
<tns:param name="myParameterName">myParameterValue</tns:param>
</tns:params>
which perfectly matches the structure in soapUI (which I already knew worked) of:
<ns:params>
<ns:param name="myParameterName">myParameterValue</ns:param>
</ns:params>