Is it possible to only allow content creators to add 1 or 2 elements in a repeatable group? I am looking for something like this:
"content_teasers" : {
"type" : "Slice",
"fieldset" : "Content Teasers",
"description" : "One or two teasers with Image, Title, Text and an optional link",
"repeat": 2,
"repeat" : {
"image" : {
"type" : "Image",
"config" : {
[...]
where "repeat": 2 sets the number of allowed elements.
No, it's not possible,
The way to do it today would be to add the fields in the non-repeatable section of a slice.
I'm part of Prismic's team so I just logged this as a feature request for the dev team!
Is it because you have strict design rules of having X number of components? or you don't want to handle the display of too many cases (if they put 1, 2, or 10 items?)
I've recently run into a similar problem but found a hacky solution that's been working for me (still hoping something is officially added to Prismic). If you add the number of items you want to your page before you add "repeat": false to your JSON config, it will keep those items but remove the ability to add more.
For anyone who comes across this, here's a snippet from one of my custom types as an example:
{
"Main": {
"title": {
"type": "Text",
"config": {
"label": "Title"
}
},
"uid": {
"type": "UID",
"config": {
"label": "uid"
}
}
},
"Hero": {
"hero_images": {
"type": "Group",
"config": {
"repeat": false,
"fields": {
"image": {...}
}
}
}
}
}
Related
I am trying to programmatically add an activity to a customer entity. I can create both a customer and a note using the API with a PUT, but I cannot figure out how to relate the activity to the customer. I viewed the JSON definition using Postman, but didn't see anything that made sense for relating it to another entity. I tried adding RelatedEntityDescription, but that unsurprisingly did not work.
Here is my JSON body for the PUT (it works but creates an un-linked activity)
{
"Body": {
"value": "message text"
},
"Date": {
"value": "2020-04-22T15:28:00.99-05:00"
},
"Summary": {
"value": "Test message"
}
}
What do I need to add to link it to my customer?
Good day Sreimer
The Table you should be saving to is Note.
It links on BAccount.NoteID and Note.NoteID.
An easy way to test this is to create and save a note on a customers and look for it in Note:
select *
from Note
where NoteText like '%test%';
You just need to specify the RelatedEntityType and RelatedEntityNoteID in your request
{
"Body": {},
"Date": {
"value": "2021-01-06T14:42:03.837-08:00"
},
"RelatedEntityNoteID": {
"value": "01a0c017-df7f-ea11-8175-b9d61cb73193"
},
"RelatedEntityType": {
"value": "PX.Objects.AR.Customer"
},
"Summary": {
"value": "Test Activity 4"
},
"Type" : {
"value" : "M"
}
}
Im trying to make a system monitor, which is highly customisable by user. This customization is achieved by using JSON file for modeling look of system monitor. The JSON could look like this.
{
"_": "WINDOW",
"name": "myWindow",
"children": [
{
"_": "CPU",
"name": "cpuMonitor",
"freq_Unit": "MHZ"
},
{
"_": "NETWORK",
"name": "network",
"unit": "Kb/s"
},
{
"_": "DISK",
"name": "disk"
}
],
"background": "red"
}
As you can see, each object coresponds to this schema.
{
"$schema": "http://json-schema.org/draft-07/schema#",
"name":"Component",
"type": "object",
"properties":{
"_": {
"type": "string"
},
"name":{
"type":"string"
},
"childern":{
"type":"array"
}
},
"required": ["_","name"]
}
But each component has also its own schema definition. I'd like to parse whole JSON and validate each node for different schema (first if its component and then to its corresponding schema).
I had look at rapidJson and other libraries, but I didnt find solution for validating nodes for different schema. Do you know any library which could do that? Or is it even possible to validate JSON in this way?
All feedback on how to solve this will be appreciated.
Edit: Corrected schema :(
There's a simple approach involved with that, use the oneOf pattern declaration to specify the layout of the array elements. Inside these nested declarations, you specify the fixed identifier (probably the content of your _ field) as a constant, so that there is only one nested schema matching each of your panel types.
Notes:
I had to specify the constant type identifier using the enum specifier because the regular constant specifier didn't work with the library I was using. This may also have been an oversight in the revision of the specification that it was based on.
A different approach is to split the the validation steps. You simply verify that the elements of the array are objects and that they have a string field _ containing one of the supported types. When iterating over the array, you then validate each field individually according to its _ field.
In addition to Ulrich's answer, here's an example of what I'd do:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Component",
"type": "object",
"definitions": {
"base": {
"properties": {
"name": { "type": "string" },
"children": {
"type": "array",
"items": { "$ref": "#" }
}
},
"required": [ "_", "name" ]
},
"cpu": {
"properties": {
"_": { "const": "CPU" },
"freq_Unit": "MHZ"
}
},
"network": {
"properties": {
"_": { "const": "NETWORK" },
"unit": "Kb/s"
}
},
"disk": {
"properties": {
"_": { "const": "DISK" }
}
},
"window": {
"properties": {
"_": { "const": "WINDOW" },
"background": { "enum": [ "red", "orange", "yellow", ... ] }
}
}
},
"allOf": [
{ "$ref": "#/definitions/base" },
{
"oneOf": [
{ "$ref": "#/definitions/cpu" },
{ "$ref": "#/definitions/network" },
{ "$ref": "#/definitions/disk" },
{ "$ref": "#/definitions/window" }
]
}
]
}
First, we require that any instance MUST adhere to base which declares _ and name as required properties. Additionally, we declare a children array property that requires all items also match this schema (giving us a recursive behavior). This doesn't really do much except that it allows us to declare these things in one place instead of having to declare them in the other three definitions.
(Note that we don't declare _ in the properties list. This means that any value will pass for this portion of the schema. We clean it up in the next part. If you want to ensure that future components are declared with strings, then you can add a "type": "string" requirement to that property, but I don't feel it's necessary unless others are authoring those components.)
Second, we declare each of our specific types as separate definitions, using the const keyword to isolate the one we want. This construct is analogous to a switch (or case) statement. If the instance doesn't match one of these explicit options, it fails. If it's missing one of the required base properties, it fails.
This will get you where you want to be.
To take it further, there are two more things you can do:
Add required to the other definitions to say that the specific properties are also required (e.g. freq_Unit for the cpu definition).
Declare each of the definitions in separate files. This would allow you to add a new definition by simply adding a new file and referencing it in the main schema. In my opinion, it's a bit cleaner. Some people prefer to have it all in one file, though.
Unfortunately I could not locate anything relevant in the Swagger v2 documentation or in SO, so I am afraid I have to create this new thread.
What I would like to understand is whether it is feasible to associate enums with each other via Swagger. Consider the scenario where our Definitions specify a "Status" with two enum properties: "Code" and "Description" as per the below excerpt:
"definitions": {
"Status": {
"type": "object",
"properties": {
"Code": {
"type": "string",
"enum": ["01", "02", "03"]
},
"Description": {
"type": "string",
"enum": ["OK", "NOK - Please retry", "NOK - Do not retry"]
}
}
}
}
How could we specify that a given "Code" may only be associated to a specific "Description" (e.g. "01" for "OK", "02" for "NOK - Please retry", etc.)?
Obviously, using a property description (which actually acts as an embedded documentation) is not the way to go when having hundreds of Codes.
Thank you!
I've been playing around with the Microsoft Academic API, trying to do graph queries using JSON formatted queries. I'm at the point where I think I can produce results, but for some reason I don't get the full set of results.
The query I am attempting to perform will retrieve all papers that reference a paper that has a FieldOfStudy that is one of the ones I'm looking for. Essentially, I'm trying to find out how well cited a field of study is.
I think the query should look something like this:
{
"path": "/paper/ReferenceIDs/reference/FieldOfStudyIDs/field",
"paper": {
"type": "Paper",
"match" : {
"PublishYear": 2017
},
"select": ["DOI","OriginalTitle","PublishYear"]
},
"reference" : {
"type" : "Paper",
"select" : "OriginalTitle"
},
"field": {
"type": "FieldOfStudy",
"select": [ "Name" ],
"return": { "id": [106686826,204641814] }
}
}
Unfortunately, I get only an incomplete subset of results. Funnily enough though, if I further restrict the initial node by matching on a title, I get another set of results (disjoint from the first query result set)
{
"path": "/paper/ReferenceIDs/reference/FieldOfStudyIDs/field",
"paper": {
"type": "Paper",
"match" : {
"OriginalTitle": "cancer",
"PublishYear": 2017
},
"select": ["DOI","OriginalTitle","PublishYear"]
},
"reference" : {
"type" : "Paper",
"select" : "OriginalTitle"
},
"field": {
"type": "FieldOfStudy",
"select": [ "Name" ],
"return": { "id": [106686826,204641814] }
}
}
So, what could be going on here? Is the query giving up because the very first node it hits on the broader search doesn't match the path? Is it even possible to query all papers published in a year like this?
Question title pretty much self explanatory. It is possible to create an id-less entity in Orion. An id = .* query returns normally as an id-less, although existing entity. But how can someone delete that entity? This request didn't work obviously:
{
"contextElements": [
{
"type": "",
"isPattern": "false",
"id": ""
}
],
"updateAction": "DELETE"
}
This is the returned query:
{
"contextElement": {
"type": "",
"isPattern": "false",
"id": "",
"attributes": [
{
"name": "temp",
"type": "integer",
"value": "15"
},
{
"name": "pressure",
"type": "integer",
"value": "720"
}
]
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
There is a known bug (now fixed) in Orion that seems to be causing your issue. Basically Orion interprets the final "/" at the end of an URL as an empty element.
For example (as documented in the issue):
v1/contextEntityTypes queries for all types, while
v1/contextEntityTypes/ queries only for the empty type
In your particular case, something similar happens with some REST operations. If you do a GET /v1/contextEntities you will see all entities, including the empty-id one. You can query that particular entity with GET /v1/contextEntity/ (note the final "/").
And then, the DELETE method doesn't seem to use the same pattern. So if you do DELETE /v1/contextEntity/ You get a No context element found.
So, basically, this is another manifestation of a known bug.