Skip to content
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

Open
wants to merge 17 commits into
base: lmi-insights
Choose a base branch
from

Conversation

MarcoBgn
Copy link
Contributor

@MarcoBgn MarcoBgn commented Mar 9, 2018

  • Initial WIP changes for the LMI feature
  • Cherry-picked Xaun's changes fixing build

@manu-d
Copy link
Contributor

manu-d commented Mar 9, 2018

@cesar-tonnoir
Can you have a look at this PR, so that I can open all my PR against maestrano's repo and not Marco's?
Thanks

Copy link
Contributor

@xaun xaun left a 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" />
Copy link
Contributor

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" />
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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])
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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="">
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -0,0 +1,32 @@
angular
.module('impac.services.highcharts-theme', [])
.service('HighchartsThemeService', (ImpacTheming) ->
Copy link
Contributor

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?

Copy link
Contributor Author

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)
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor

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?

@MarcoBgn MarcoBgn requested a review from xaun March 28, 2018 10:18
Copy link
Contributor

@xaun xaun left a 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.

@agranado2k agranado2k modified the milestones: v1.9.0, LMI Jun 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants