Closed alansemenov closed 3 years ago
I would prefer to break this functionality, and release version 6 instead. It is likely that it has not been used much, given its current state and no complaints.
As such, lets keep x. and xAsJson
We don't have xAsJson
now, that's what we were going to add with this task (and keep old x
deprecated).
Ah, then we can indeed start by doing that, and create another task to perform the fully typed implementation.
So, conclusion:
we deprecate x. we implement xAsJson Output should look similar to the node JSON. i.e:
"x": {
"com-enonic-app-hmdb": {
"SoMe": {
"imdb": "12",
"twitter": "123",
"instagram": "1234"
}
}
}
@sigdestad Should we support x
as type as alternative asJson
to fetch specific fields?
@anatol-sialitski Not sure if I understand the question? Plan is to keep x as it is, and then release 6.0 where x. becomes a fully typed version.
So this release will be 5.1
This properties structure of x-data:
Will be rendered like this by guillotine
x.data
looks like an array-to-string conversion which is very difficult to parse.Deprecate current fields and implement the new one called
xDataAsJson
andxData
which will have similar structure tomacroAsJson
etc.: