What is the proper way to achieve the visual equivalent of this:
, but for an array that is part of the entity of the Resource itself (as opposed being a field on a referenced entity)? For instance, if my document looked like {"id": 1, "title": "my title", "comments_by": ["john", "kate"]}.
I tried to nest a List element but wasn't able to make it look right.
You're on the right track; This should achieve your goal:
<FunctionField render={record=>
record.comments_by.map((by,index)=> <ChipField record={{by}} source="by"/>)
}/>
Related
How to extract a item from compose.
For example I have a compose item like below,
How to get "AAAA" only and input create a item to sharepoint List.
I tyied
outputs('Select')?['Title']
Appear Error msg like that "Array elements can only be selected using an integer index."
Compose
{ "Titile" : "AAAA",
"TitleB" : "BBBB",
"TitleC" : "CCCC",
"TitleD" * "DDDD}
Firstly, your JSON is far from being valid so I've made some assumptions and have included it here with what I used for my answer ...
{
"TitleA": "AAAA",
"TitleB": "BBBB",
"TitleC": "CCCC",
"TitleD": "DDDD"
}
My suggestion is that you use variables instead of compose.
Here is my flow ...
With the second step, this is the expression I used ...
variables('Json Object')?['TitleA']
This is the end result ...
I'm practicing d3 with Mike Bostok's example: https://bl.ocks.org/mbostock/3884955
I'd like to see how the series that he made - cities - looks like.
I opened the html file using Python local server and in the console, I wrote 'console.log(cities);' but it didn't work. 'console.log(data);' also didn't work. They all showed this error message:
VM100:1 Uncaught ReferenceError: cities is not defined
at <anonymous>:1:13
I didn't make any modification in his code. So I don't think there is an error in the code. I assume perhaps the problem is in line with d3 setting?
So, I've tried to open the file in Firefox and I've also downloaded d3 but those two ways also didn't work.
Does anyone happen to know what is the cause of the problem?
If someone can explain how the 'cities' in his code looks like, then you are the most welcome!
Thanks a lot,
At a guess, the reason cities is undefined is because your console.log statement is somewhere outside of the callback function provided to d3.tsv. If you look closely at Mike's code, you'll notice that the third argument to d3.tsv is a function that receives as an argument an error object and the processed data. Inside that function, he defines the cities variable, so if you put console.log(cities) anywhere outside of that function, cities will be undefined.
Now, on to the format of the data. If you look further down that block, there's another file: data.tsv. It has four columns: date, New York, San Francisco, Austin. d3.tsv will create an array where each element in the array corresponds to one row in the TSV (except for the header row). Each row is converted to a plain JavaScript Object with properties that correspond to the columns of the file. That array is passed into the callback as the data variable in this block. So data[0] will be
{
"date": "20111001",
"New York": "63.4",
"San Francisco": "62.7",
"Austin": "72.2"
}
When the cities variable is defined, that array is transformed into an array that contains one item per city, and each object representing the city contains the time-series data of temperature for that city. So the cities variable will look like:
[
{
"id": "New York",
"values": [
{"date": Date 2011-10-01T00:00:00, "temperature": 63.4},
{"date": Date 2011-10-02T00:00:00, "temperature": 48.0},
...
]
},
{
"id": "San Francisco",
"values": [...]
},
{
"id": "Austin",
"values": [...]
}
]
It's probably worth pointing here the second argument to d3.tsv in this example: the type function. This is where all the strings are converted into Date or Number objects. Without this argument, all of the property values in data would be strings.
For more information on how d3.tsv works, you can check the docs for d3-request.
CAVEAT: that block is for d3v4, the latest version of d3 is v5. In v5, d3-request is deprecated in favor of d3-fetch. d3-fetch provides pretty much the same set of utilities for fetching data, but instead of using callback functions, they return Promises.
How can I use MS Flow to select an individual object, by value for a specified property, from an array?
Example array:
[
{
item_id: '1234'
},
{
item_id: '4567'
}
]
In the example above, I may only want to work with the first object and the rest of its available properties.
Happy to use the Workflow Definition Language and/or any of the Data Operations actions.
I solved this by using the "Data operations - Filter" action.
Ignore the error in red - it is an array.
My left-hand expression for "item_id" is:
item()?['item_id']
And then I statically enter the item ID I wish to access in the right-hand input.
DocumentNo Item will then be an array itself with only 0 or 1 elements and can be used like so:
body('DocumentNo_Item')?[0]?['label']
Is it possible to search an account's custom data to find a value contained in an array?
Something like:
?customData.[arrayName].{key}=value
The Stormpath docs don't mention array searching.
Yes, with Stormpath it is totally possible to search for custom data even if the values are stored as an array!
Please note that the field names are simple names, and the values are what are different data types like array, map, string etc... so the query is not as complex as one would think :-)
For example, if I want to store custom data called favoriteColors, which is an array like
"favoriteColors": [ "red", "black", "blue", "white" ]
Notice the field name is just like any other field name. The value is the array.
To search for accounts which have a value red in the favoriteColors array, you just need the normal query syntax:
?customData.favoriteColors=red
The full request (if searching a Directory of accounts), might look like this:
https://api.stormpath.com/v1/directories/<directory_uid>/accounts?customData.favoriteColors=red
You could also do the same search on the Tenant resource to search tenant-wide (across all accounts):
https://api.stormpath.com/v1/tenants/<tenant_uid>/accounts?customData.favoriteColors=red
This query would match an account that contains red in the favoriteColors array. If I changed the query to ?customData.favoriteColors=yellow it would not match unless yellow was also added to the array.
Searching for custom data in an array can definitely be done. The syntax is: customData.{fieldName}\[{index}\]=value where {index} can be the specific index you are looking for, or * if you want to find it anywhere in the array. (Note that the [] characters are escaped with a backslash or the query interpreter gets it confused with a range query.)
If you leave off the index entirely, then \[*\] is implied. More precisely, Stormpath will check for either the value in the fieldName or the value as an element in an array of fieldName. However, syntactic sugar can only work if the array field is the last element in your search. Since you can put literally any JSON object into your custom data, Stormpath cannot check every single possibility. Imagine something like customData.foo.bar.baz.qux=bingo. Stormpath would not try to guess that maybe foo is an array, maybe bar is an array or not, maybe baz is an array or not - only maybe qux is an array or not. So, if you want to search an array of objects, you cannot leave out the \[*\].
Here is an example. I have an account with the custom data:
{
"favoriteThings": [
{
"thing": "raindrops",
"location": "on roses"
},
{
"thing": "whiskers",
"location": "on kittens"
},
{
"thing": "snowflakes",
"location": "on my nose and eye lashes"
}
],
"favoriteColors": [
"blue",
"grey"
]
}
The following queries will yield the following results:
customData.favoriteColors=blue will include this account.
customData.favoriteColors\[1\]=blue will not include this account because blue is not at index 1.
customData.favoriteThings\[*\].thing=whiskers will include this account
customData.favoriteThings\[*\].thing=ponies will not include this account because it does not list ponies as one of his favorite things, but may include other accounts with custom data in the same structure.
customData.favoriteThings.thing=whiskers would not include this account or any other accounts with the same custom data structure because in that case, Stormpath would be looking for a single nested JSON favoriteThings object, not an array.
While creating a document that is got from web interface, it does not rightly typecast integer date and other type. for example
{"_id": "<some_object_id>", "name": "hello", "age": "20", "dob": "1994-02-22"}
Since attributes are entered dynamically, their types can not be prejudged. Is there any way I can get them entered from client side, like
{"_id": "<some_object_id>", "name": "hello", "age": "$int:20", "dob": "$date:1994-02-22"}
Any help is highly appreciated.
Since you appear to be concerned about the strings that come in from a form such as a POST, the simple answer is that you cast them in Ruby.
If the field is what you expect to be a number then cast it to an int. And the same goes for dates as well.
Your mongo driver will correctly interpret these and store them as the corresponding BSON types in your MongoDB collection. The same goes in reverse, when you read collection data you will get it back cast into your native types.
"1234".to_i
Date.strptime("{ 2014, 2, 22 }", "{ %Y, %m, %d }")
But that's be basic Ruby part.
Now you could do something like you pseudo-suggested and store your information, not as native types but as strings with some form of type tagging. But see, I just don't see the point as you would have to
Detect the type at some stage and apply the tag
Live with the fact that you just ruined all the benefits of having the native types in the collection. Such as query and aggregation for date ranges and basic summing of values.
And while we seem to be going down the track of the anything type where users just arbitrarily insert data and something else has to work out what type it is, consider the following examples of MongoDB documents:
{
name: "Fred",
values: [ 1, 2, 3, 4],
}
{
name: "Sally",
values: "a"
}
So in Mongo terminology, that document structure is considered bad. Even though Mongo does have a flexible schema concept, this type of mixing will break things. So don't do it, but rather handle in the following way, which is quite acceptable even though the schema's are different:
{
name: "Fred",
values: [ 1, 2, 3, 4],
}
{
name: "Sally",
mystring: "a"
}
The long story short, Your application should be aware of the types of data that are coming in. If you allow user defined forms then your app needs to be able to attach a type to them. If you have a field that could be a string or a Date, then your app need to determine which type it is, and cast it, or otherwise store it correctly.
As it stands you will benefit from re-considering you use case, rather than waiting for something else to work all that out for you.