NotionCommotion

Is there a "better" way to do this? Desired result is PHP equivalent to {name:"my name", data: [4,6,8]}. private function makeNameDataObject($name,array $data) { $obj = new stdClass; $obj->name=$name; $obj->data=$data; return $obj; }

Long pool is typically referred to as an Olympic size pool. Please see: https://en.wikipedia.org/wiki/Olympic-size_swimming_pool.

Thanks Barand, but this would require a value for each series or category. Guess I will just do it in two queries: one to get say the series with a left outer join for values, and group_concate the values, and a second query for the categories.

Data is user inputted and if they want, they will have to re-input data for the next chart, however they will most likely not want to. Actually I am still stumped as the cross table may not have a record for a given series/category and I therefore can't always join series and.categories.

Agreed, however this is acceptable. Thanks

EDIT. Never mind. I should be able to figure this out using GROUP_CONCAT and a loop. Can't seem to delete the post, however. I would like a generic approach to store and display matrices such as the following. To store the data, I am thinking of the following schema. While this is a PHP question, if you feel I haven't modeled it correctly, please advise. Given the chart ID, how would it be best to retrieve the data and create the table?

So, it cannot be done via PHP, but require Apache/nginx/etc configuration? The PHP server script will be ran by others, and I don't wish to complicate there setup.

I am building an API which will provide services to a PHP client (PHP is acting as a server to the browser, but acts as a client to the API). One of the functions the API does is create png images. The browser client needs to access these images. I would rather the browser client not directly access the API server, but only access the PHP webserver. I would also rather not require the PHP server to need to store a copy of the png image. Can I somehow proxy the image so that the browser client directly accesses the webserver and can download the image?

I agree with your point about making it more difficult to identify errors. Also, no emulated prepared statements here (learned that from you). If not as I showed, what would possible be a good use of PDO exceptions?

Yes, I am using the database system to validate the input. Why not? It is validated client side, and as such I expect only exceptions due to malicious behavior. I recognize that one can use a separate try statement for each query, but it doesn't help for code conciseness and readability. I was thinking of just placing a string $cause_of_error='Foo caused the error!'; before each statement. Thanks

I have the following queries where foo.x, bar.x, and foobar.bla are foreign keys. The JavaScript client "should" only pass valid data, so I expect it is rare that an exception will occur. How best to determine which query caused the exception in the try block? try { $this->db->beginTransaction(); $stmt=$this->db->prepare('INSERT INTO foo(id,x,y,z) VALUES(0,?,?,?)'); $stmt->execute($foo); $foo_id=$this->db->lastInsertId(); $stmt=$this->db->prepare('INSERT INTO bar(id,x,y,z) VALUES(0,?,?,?)'); $stmt->execute($bar); $bar_id=$this->db->lastInsertId(); $stmt=$this->db->prepare('INSERT INTO foobar(foo_id,bar_id,bla) VALUES(?,?,?)'); $stmt->execute([$foo_id,$bar_id,$bla]); $this->db->commit(); $rs=['status'=>true,'foo_id'=>$foo_id,'bar_id'=>$bar_id]; } catch(PDOException $e){ $this->db->rollBack(); $rs=['status'=>false,'error'=>'???']; }

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.

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.

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.

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.

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

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: There is no referential integrity requirements. There will never be any requirement to query the individual data held within the JSON. 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. The data is only being used to populate a JavaScript application. 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?

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} ] } ] }

Well, it is the thought that counts

Thanks Barand, I too was thinking of my second approach, but wanted another opinion. And thank you too for the implementation script. I rarely use list(), but probably should do so more often.

I've got the following two tables and wish to create the following array. What is the best way to create the array? Thanks Do the first query and loop through them using PHP, and then a prepared statement for the second? Inner join the two tables, loop through them using PHP, and set an array if not currently set, and if set, just add to the array? Inner join the two tables, and use GROUP_CONCAT and then explode()? While I think this approach is slick, I don't want to use it due to the truncation limitation. Something else? Companies 1 Ford 3 General Motors 5 Chrysler Cars 1 1 Mustang 2 1 Fusion 3 3 Corvette 4 3 Escalade 5 5 Charger 6 5 Challenger $cars=[ [ 'id'=>1, 'name'=>'Ford', 'cars'=>[ ['id'=>1, 'Mustang'], ['id'=>2, 'Fusion'] ] ], [ 'id'=>3, 'name'=>'General Motors', 'cars'=>[ ['id'=>3, 'Corvette'], ['id'=>4, 'Escalade'] ] ], [ 'id'=>5, 'name'=>'Chrysler', 'cars'=>[ ['id'=>5, 'Charger'], ['id'=>6, 'Challenger'] ] ] ];

I agree implementing ever little feature of Highcharts isn't really necessary. I just didn't know if I would later discover some user need which would require JavaScript. For now, I will not attempt to do so. Thanks

Your hopes have been met. I don't want the first scenario! Regarding color, I agree there are better strategies which don't require storing and running arbitrary JavaScript code. There are other times, however, when JavaScript is used in the configuration, and I may not be able to use some sort of preprocessing. Unless I can come up with a good way of deal ling with them, it seems like maybe I should not even attempt to support these other cases.

On my second post, I added the cryptic "I just recalled that I plan on storing data in the string, so it needs to be well formed JSON no matter which option I take.", so this is not so easy. My reason is I wish to be able to change, for instance, just the title. Sure makes it easier if it is JSON. For color, I can keep it all server-side, so I don't have the need to store script. There is also some other cases, however, where JavaScript is used in the Highchart config, and it would be nice to be flexible enough to handle these cases when they become evident.

I just recalled that I plan on storing data in the string, so it needs to be well formed JSON no matter which option I take. Here are my thoughts: Authorized user adds the initial JSON such as: '{"foo":"bar","script":"{{ javascript(); }} }'. PHP confirms the string is well formed and identifies the nodes which have the {{ }} deliminator. These node locations are stored in the JSON as meta data, and maybe the deliminator are stripped. Either:The JSON which includes the script node meta data are sent to the client via JSON, and the client takes appropriate action on the script nodes. Two copies of the string are stored: one which is JSON and the other which is used to write the JavaScript on the client. If the string needs to be edited, the deliminators are reinserted by the server allowing the authorized user to edit. Thoughts?