From discussions we had a few theoretical ideas:
- There should be a clear distinction between format and content: output/results formatting should in principle be done in the JSON, and the content should come from R. Ideally, in R you would not need to think about formatting of the output anymore. See point 6 of the to do list below.
- There should be a clear definition of static and dynamic: There are a few levels of how dynamic a results object is;
- Static - the results object does not change its column names, attributes, formatting, etc. This can be formatted fully in the JSON.
- Dynamic 1 - the results object has titles or column names or other formatting that changes based on the options entered in the UI. For the most part, this is still fully formattable in the JSON (extra columns can be entered but not returned by R, for example)
- Dynamic 2 - the formatting and size of the table might depend on the data or levels of a factor. This cannot be done with JSON as it is not a programming language. Formatting needs to be done in R with proper default formatting -- see point 5.
container
typetitle
key - it does not work when you specify atitle
key in thecontainer
type results object of the JSON: the title is not properly displayed in the output.container
typeitems
key - Just like its parentresults
, this key should contain an array of objects, for example like so:
{
"name": "plots",
"type": "container",
"title": "Plots",
"items": [
{
"name": "distPlots",
"type": "image",
"width": 320,
"height": 240
},
{
"name": "matrixPlot",
"type": "image",
"width": 500,
"height": 500
},
{
"name": "splitPlots",
"type": "image",
"width": 320,
"height": 240
}
]
}
- Non-alphabetic ordering of
container
items - the items should use thename
key to order the contents in the order they have in the JSON, just like in theresults
. - Dynamic
overTitle
- currently, it is possible in the new analyses to enter anoverTitle
in the JSON. As an example: look at the main table of Descriptives with a factor in the - Dynamic column addition - some tables are dynamic and require the number of levels from the data for determining how many columns are needed. However, we will still want to output data frames for this purpose. Something like a
jasp.format
attribute to thejasp.data.set
class needs to be developed in order for this to work, and what is now calledcommon.R
needs to be edited to accept extra columns not documented in the JSON. - R results without structure - In the case of static or dynamic 1 results objects, the R results should be returnable without structure. For the following results JSON:
{
"results": [
{
"name": "statsTab",
"type": "table",
"title": "Descriptives"
},
{
"name": "freqTabs",
"type": "table",
"title": "Frequencies"
},
{
"name": "plots",
"type": "container",
"title": "Plots",
"items": [
{
"name": "distPlots",
"type": "image",
"width": 320,
"height": 240
},
{
"name": "matrixPlot",
"type": "image",
"width": 500,
"height": 500
},
{
"name": "splitPlots",
"type": "image",
"width": 320,
"height": 240
}
]
}
]
}
it should be possible to return results in this way:
results <- list(
statsTab = statsTab,
freqTabs = freqTabs,
distPlots = distPlots,
matrixPlot = matrixPlot,
splitPlots = splitPlots
)
This way, the container
logic remains within the JSON and can be edited easily.
common.R
should be split into several well-named parts for clarity. I don't know if it's possible, but it would be nice to have ajasp-desktop\JASP-Engine\JASP\R\common
subfolder for this with files likebridge.R
,parsing.R
,jasp.data.frame.R
as needed.
Looks great! Just one thing: It looks like there is one or multiple words missing at the end of point no 4