Сделайте ваш PHP-скрипт возвратом JSON, содержащим как результаты html, так и новое значение из сеанса. Затем в вашем обратном вызове вы обновляете все, что необходимо обновить, с помощью значения сеанса.
Вы должны переместить ваше условие на достаточно высокий уровень, чтобы иметь возможность ссылаться на все свойства, на которые оно должно ссылаться. В данном случае это схема /definitions/Base
. Тогда вам просто нужно правильно написать свои схемы, как объяснил Relequestual.
{
"$ref": "#/definitions/Base",
"definitions": {
"Base": {
"type": "object",
"properties": {
"session": { "$ref": "#/definitions/Session" },
"sdk": { "$ref": "#/definitions/SDK" }
},
"allOf": [
{
"if": {
"properties": {
"sdk": {
"properties": {
"name": { "const": "ios" }
}
}
},
"required": ["sdk"]
},
"then": {
"properties": {
"session": {
"properties": {
"session_id": { "pattern": "A" }
}
}
}
},
"else": {
"properties": {
"session": {
"properties": {
"session_id": { "pattern": "B" }
}
}
}
}
}
]
},
...
}
Я думаю, что у вас есть та же проблема, что и в , этот вопрос .
@Relequestual прав в том, что вам нужно ключевое слово properties
вокруг вашей выноски SDK
. Но для того, что вы хотите сделать, вам нужно реорганизоваться.
Подсхемы работают только на своем уровне в данном случае, а не в корне.
Рассмотрим эту схему для простого экземпляра объекта JSON, содержащего свойство one
и two
:
{
"properties": {
"one": {
"enum": ["yes", "no", "maybe"]
},
"two": {
"if": {
"properties": {
"one": {"const": "yes"}
}
},
"then": {
... // do some assertions on the two property here
},
"else": {
...
}
}
}
}
Ключевое слово if
в свойстве two
может учитывать только часть экземпляр в свойстве two
(то есть значение two
). Он не смотрит на корень экземпляра, поэтому он вообще не может видеть свойство one
.
Чтобы подсхема в подсхеме свойства two
могла видеть свойство one
в экземпляре, необходимо переместить if
за пределы ключевого слова properties
.
{
"if": {
"properties": {
"one": {"const" : "yes"}
}
},
"then": {
... // do some assertions on the two property here
},
"else": {
... // assert two here, or have another if/then/else structure to test the one property some more
}
}
Для двух возможных значений one
это довольно хорошо. Даже три возможных значения неплохо. Однако с увеличением возможных значений one
увеличивается и вложенность if
с, что может сделать вашу схему ужасной для чтения (и, возможно, сделать проверку медленнее).
Вместо использования конструкции if
/ then
/ else
я предлагаю использовать anyOf
или oneOf
, где каждая подсхема представляет действительное состояние для экземпляра, учитывая различные значения one
.
{
"oneOf": [
{
"properties": {
"one": {"const": "yes"},
"two": ... // do some assertions on the two property here
}
},
{
"properties": {
"one": {"const": "no"},
"two": ... // do some assertions on the two property here
}
},
{
"properties": {
"one": {"const": "maybe"},
"two": ... // do some assertions on the two property here
}
}
]
}
На мой взгляд, это намного чище.
Надеемся, что это объяснение поможет вам реконструировать вашу схему, чтобы позволить другим экземплярам пройти.
Значение if
должно быть схемой JSON. Если бы вы взяли строки https://gist.github.com/Relequestual/f225c34f6becba09a2bcaa66205f47f3#file-schema-json-L29-L35 (29-35) и использовали это как схему JSON самостоятельно, вы бы не навязывали никаких проверочных ограничений, потому что на верхнем уровне объекта нет ключевых слов схемы JSON.
{
"SDK": {
"properties": {
"name": {
"enum": "ios"
}
}
}
}
Это разрешено в спецификации, потому что люди могут захотеть расширить функциональность схемы JSON, добавив свои собственные ключевые слова. Так что это «правильная» схема JSON, но на самом деле ничего не делает.
Вам нужно добавить properties
в схему, чтобы она имела смысл.
{
"properties": {
"SDK": {
"properties": {
"name": {
"const": "ios"
}
}
}
}
}
Кроме того, enum
должен быть массивом. Если у вас есть только один предмет, вы можете использовать const
.