-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/lmi insights #487
base: lmi-insights
Are you sure you want to change the base?
Feature/lmi insights #487
Conversation
MarcoBgn
commented
Mar 9, 2018
•
edited
Loading
edited
- Initial WIP changes for the LMI feature
- Cherry-picked Xaun's changes fixing build
…-improvement [IMPAC-741] Lmi widgets improvement
…o feature/lmi-insights
@cesar-tonnoir |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern is with the size & duplication of the chart.formatter()
overrides across the custom widget templates. Other than that, just some incorrect code from the widget generator, and commented code left in.
</div> | ||
|
||
<!-- No data found --> | ||
<div ng-if="(isDataFound==false)" common-data-not-found on-display-alerts="onDisplayAlerts()" endpoint="::widget.category" width="::widget.width" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the old implementation of the data-not-found directive. I know the generator created it, but its out of date. I updated this in the generator in v1.6.9 but the lmi feature branch is behind.
The data-not-found is now a modal, so no need to show/hide content on $scope.isDataFound. Replace this directive with: <div ng-show="widget.demoData" common-data-not-found />
.
Take a look at cash projection template for example, test with a bolt widget for org with no bolt data.
</div> | ||
|
||
<!-- No data found --> | ||
<div ng-if="(isDataFound==false)" common-data-not-found on-display-alerts="onDisplayAlerts()" endpoint="::widget.category" width="::widget.width" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above
# == Chart Events Callbacks ===================================================================== | ||
# Sets the transactions list resources type and displays it | ||
# onClickBar = (event) -> | ||
# $scope.isChartDisplayed = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clean up commented code?
|
||
# == Directive Events Callbacks ===================================================================== | ||
# $scope.onButtonBack = () -> | ||
# $scope.isChartDisplayed = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commented code
formatter: -> | ||
$filter('mnoCurrency')(this.value, currency, false) | ||
xAxis: angular.merge([w.content.chart.xAxis[0]], [xAxisLabels]) | ||
yAxis: angular.merge([w.content.chart.yAxis[0]], [yAxisLabels]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The yAxisLabels are the same as default (right?), for overriding the formatters method, I suggest leveraging the formatters method's returned defaults by savings them to a variable in the outer scope.
Also, rather than having to merge the new v2 bolt layouts response options (xAxis, yAxis, tooltip etc) for every single custom widget template, the highcharts factory should be extended to use these by default.
Then you could do this sort of thing:
defaultFormatters = $scope.chart.formatters()
$scope.chart.formatters = ->
defaultFormatters.labels.formatter = ->
formatString = if this.chart.rangeSelector.options.selected >= 3 then 'MMM YYY' else 'DD MMM'
moment.utc(this.value).format(formatString)
defaultFormatters.rangeSelector = { selected: 5 }
defaultFormatters
EDIT: so I can see now that you have extended the highcharts formatter, so would simply be saving the defaultFormatters
be enough to not have to do the angular.merge([w.content.chart.xAxis[0] .. )
? Seems like you are giving the formatter the w.content.chart.xAxis in initialization, but then having to re-provide it with it to merge in the custom opts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xaun I am not completely sure about this as there seem to be slight differences in the overridden formatters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarcoBgn Im not completely across the intricacies of your customisations, so my solution isn't comprehensive for your use-case. I am just showing you a way you can store the existing defaults, then modify the object and reassign the formatters method.
The main thing is, this method is massive in the widget controller, it redefines some values that are already defined in the default, and looks very similar across all of the new widgets. So for my review, I request that we think of a solution to improve this. If this is not in the scope of this body of work, or it needs to be quick & dirty merged or something, that's another story :)
<!-- Content Panel --> | ||
<div ng-hide="widget.isEditMode"> | ||
<!-- Data found --> | ||
<div ng-show="isChartDisplayed" class=""> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does isChartDisplayed
ever get set false?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@manu-d as discussed could you check this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@manu-d ?
@@ -0,0 +1,32 @@ | |||
angular | |||
.module('impac.services.highcharts-theme', []) | |||
.service('HighchartsThemeService', (ImpacTheming) -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks more like something that should live in an angular .run()
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am having issues with Highcharts.theme =
where Highcharts is not defined yet. Not being a service (i.e. no HighcartsProvider), I am not sure this can live in a run() function
@@ -63,7 +69,7 @@ angular | |||
return @ | |||
|
|||
template: -> | |||
@_template.get(@data.series, @options) | |||
@_template.get(@data.series, @options, @data.xAxis, @data.yAxis, @data.plotOptions) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok for now, @cesar-tonnoir will latest 1.6 be back-merged into lmi? If so there will be lots of conflicts as this whole factory has been reworked (#480) to simplify providing options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xaun I don't think that will be necessary: the LMI widgets will use the figure+chart generic template (will be developed in 1.8 with your implementation of generic templates loading), so ultimately we shouldn't need that many customisations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cesar-tonnoir when you say "will be developed", is that different to merging this branch into upstream/1.x ? Seems there is quite a bit of HighchartsFactory#formatter customisation (of which I am not too happy with the resulting code), will the formatter stuff be discarded for generic templates? Or will it live separately somehow?
1d8d979
to
00b562f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im not really sure about whether these works are going to be merged into upstream branches. From @cesar-tonnoir's previous comment it looks like lmi widgets are going to use generic templates? So does that mean these widget controllers are going to be retired? If not, my review is that the formatters methods need refactoring.