Sorry for the long pause since the last post - I was working on providing support for saving/loading report templates.
Then, Brian and Jaap asked me to use jQuery dialogs rather than basic js-prompts and CRM alerts and notifications instead of js-alerts. I then added support for saving report template by the means of a jQuery dialog which is quite similar to the one with js-prompt. Rest was again similar to the previous one. The code lives in this branch:
Then comes the trickier part - to load one of the saved templates. This is how I have worked it out - when user clicks 'Load' button, a jQuery dialog appears with a dropdown populated with the list of saved templates (obtained by firing an Ajax call inside the callback function under `open` param of the dialog), from which user selects one and presses 'Ok' which fires another Ajax call that gets the selected report template from the database table and overrides the existing configuration of the pivot table. The code lives in this branch:
Overriding the existing pivot table configuration JSON with the loaded configuration JSON and forcing the pivot table to refresh itself to accommodate the new changes was slightly tricky. After trying to refreshing/resetting the div which contains the pivot table and failing at it, finally the pivottable.js documentation helped. Setting the 'override' param of the 'pivotUI' to `true` solved the issue.
One more thing which I worked on recently was supporting field names with comma(s) in them, which might cause the pivot table to not load such fields properly, owing to the fact that they are stored in a comma-separated array. The configuration JSON treats such fields normally - for example: if the rows of the pivot table are - 'contribution one' and 'contribution two, with comma' , then `rows` key of the configuration JSON will have this value: ['contribution one','contribution two, with comma'].
But when this value is written to database, it is saved as a comma-separated string which is the central issue because it consumes the comma present in the given field name. This could pose problem when we are trying to load such a configuration because it might consider them as multiple fields, each separated by a comma. For example in the above case -- ['contribution one','contribution two','with comma'].
As of now, I have joined this array using a special delimiter '#' to yield a string which is stored into the database and later fetched and split using this same delimiter to obtain the required array of field names. For the above case, 'contribution one#contribution two, with comma' <- this is the string which gets stored in the 'rows' param of the JSON object.
This hack solves the problem with comma-containing field names. I am yet to hear from Jaap and Brian about the same.
That's all for now! Thanks everyone for reading up to this point