Allowing user to edit JSON

[NotionCommotion]

I will be storing various Highcharts configuration files as JSON text in a database, and will be creating an API to allow the user to change it.

 

One option is to use a POST such as {task: ”updateTitle”, chartID: 123, value: “My New Title”}.

 

I know often it is recommended to decoupling the backend from the client, but the Highcharts configuration object is nothing secret, and think there might be a better way.   Any thoughts about posting something like the following, and then having the server parse it?  Or maybe use PHP notation instead of JavaScript?  Or maybe send an object instead of the text map?  Recommendations on how to implement?

{task: "updateObject", chartID: 123, element: "title.text", value: "My New Title"}
{task: "updateObject", chartID: 123, element: "series[0].data[2].name", value: "My New Browser"}
{task: "deleteObjectElem", chartID: 123, element: "series[0].data[2]"}
{task: "addObjectElem", chartID: 123, element: "series[0]", value: "{"name": "Another Browser","y": 12.33}"}

Side note.  If PHP supported PUT and PATCH, which method should be used for the above 4 server calls?

 

{
    "chart": {
        "type": "pie"
    },
    "title": {
        "text": "Browser market shares January, 2015 to May, 2015"
    },
    "series": [
        {
            "name": "Brands",
            "colorByPoint": true,
            "data": [
                {"name": "Microsoft Internet Explorer","y": 56.33},
                {"name": "Chrome","y": 24.03},
                {"name": "Firefox","y": 10.38},
                {"name": "Safari","y": 4.77},
                {"name": "Opera","y": 0.91},
                {"name": "Proprietary or Undetectable","y": 0.2}
            ]
        }
    ]
}

 

[ginerjm]

I may get my head bit off here, but here goes.

 

Data is data.

 

RDBMS is a tool/environment for data.

 

JSON is a tool for passing data - not for safekeeping.

 

My point is - Don't store your data in a db in json format. Store it like you would any data and then when you need to encode it for a purpose, do so with the appropriate function.

[NotionCommotion]

Hi ginerjm,

 

I don't think you are going to get your head bit off, and most will recommend not storing data in JSON.  For this case, however, I believe it makes sense for the following reasons:

1. There is no referential integrity requirements.
2. There will never be any requirement to query the individual data held within the JSON.
3. 99.9% of the time, I need the data in JSON format so I could send it to the client, and 0.1% of the time I need it in a PHP array so I could manipulate it, and don't want the extra overhead.
4. The data is only being used to populate a JavaScript application.
5. I will also be allowing the user to edit the entire JSON text and will only be validating certain parts server-side.  There are some properties which I don't wish to model, and using JSON allows me to do so.

If right or wrong the data is being stored as a JSON string, do you have recommendations what should be used to target specific properties so they may be changed?

[NotionCommotion]

Below is an untested possible implementation.  The intent is to change "Firefox" to "My New Browser".  I don't think $prop acts as a reference to $obj, so will probably need to figure something slightly different out.

function getFromDB($id) {
$db[123]='{
    "chart": {
        "type": "pie"
    },
    "title": {
        "text": "Browser market shares January, 2015 to May, 2015"
    },
    "series": [
        {
            "name": "Brands",
            "colorByPoint": true,
            "data": [
                {"name": "Microsoft Internet Explorer","y": 56.33},
                {"name": "Chrome","y": 24.03},
                {"name": "Firefox","y": 10.38},
                {"name": "Safari","y": 4.77},
                {"name": "Opera","y": 0.91},
                {"name": "Proprietary or Undetectable","y": 0.2}
            ]
        }
    ]
}';
return $db[$id];
}


$_POST=['task'=>'updateObject', 'chartID'=123,'node'=>'series[0].data[2].name', value=> 'My New Browser'];  //From client

$json=getFromDB($_POST['id']);
$obj=json_decode($json);
$prop=$obj;


//From client
$_POST['elem']="series[0].data[2].name";


$elem=explode(".",$_POST['elem']);
foreach($elem as $node) {
   if($pos = strpos($node, "[")){
      $index=substr($node,-$pos+1,-1);
      $node=substr($node,0,$pos-1);
      $prop=$prop->{$node}[$index];      
   }
   else {
      $prop=$prop->{$node};
   }
}


$prop=$_POST['value'];

$json=json_encode($obj);
//Save $json in database for id 123

[Jacques1]

Leaving the JSON discussion aside:

 

How do your users edit the configuration? Graphically? Then why don't you use the same GUI for creating/editing a chart and simply overwrite the entire configuration?

 

Trying to update individual parts will be very tedious and undermines your initial justification for JSON. If you want fine-grained control over the configuration, JSON is not the right approach.

Edited August 3, 2016 by Jacques1

[NotionCommotion]

Thanks Jacques1,

 

Not really graphically.  They would select a chart type from a select menu and input a unique name so they can identify the chart in the future.  They can then add/delete series to the chart.

 

The application would only give the ability to change limited portions such as the main chart title and the individual series legends, and would do so on a per-property basis (i.e. the server would get a request to change a single property to a new value).  To change the main title, wouldn't it be as simple as $obj=json_decode($json_from_db); $obj->title->text="new title";, and then encode the object and store it back in the database?

 

If they want to do more than this, they would write their own JSON which would replace the JSON in the database.

[NotionCommotion]

After giving a little more thought, I now feel my (in my head) slick idea of receiving a "map" from the client to the server property is not so slick.  What if given my particular application the location of a property is not the same for all chart types?  I think it is better for the server to just receive "updateTitle" and figure out how to do so.  Maybe not, but that is how I feel at this instance.

[NotionCommotion]

Still would opinions why storing data this way will cause issues other than lack of referential integrity and inability to properly query on a column.

[Jacques1]

• no type safety (unless you're using PostgreSQL which has a JSON type)

race conditions due to the two-step updates (load then save) if no synchronization is used

inefficiency due to the need to always load the entire document into the application

[ginerjm]

Still would opinions why storing data this way will cause issues other than lack of referential integrity and inability to properly query on a column.

I think your question/statement answers itself. One of your points refers to proper storage of data in general and the other goes right to the heart of the matter when discussing data storage - How to Get It Back.

[Jacques1]

Are you volunteering to rebuild the entire Highcharts configuration structure with normalized tables and write the code for converting the two?

[NotionCommotion]

Are you volunteering to rebuild the entire Highcharts configuration structure with normalized tables and write the code for converting the two?

 

Sweet!

 

PS.  Thanks for the list of reasons why doing so might not be the best choice.  They will either make me change my decision or find ways to overcome them.

Edited August 5, 2016 by NotionCommotion