-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Summary Widgets #1668
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
Summary Widgets #1668
Conversation
Update view provider to allow metadata definitions and to play nicely with old style views. Spec out some updates to ViewProviders and ViewRegistry to support further use of views.
Add a summary widget domain object type Implement basic interface and style configuration for rules
Add rule configuration inputs, populated with domain objects, metadata, and appropriate operations for a given type
Fixes #1654 Updated font files and icomoon json file;
Fixes #1654 Markup cleanups
Add delete functionality and UI Improve process for indexing and rendering rules to support deletion, and eventually reordering Fix bug where default style was passed by reference and overwritten on style updates
Fixes #1654 Ported .inspector-config SCSS from _inspector.scss and renamed to .l-compact-form;
Fixes #1654 New SCSS for widgets; markup mods in progress
Fixes #1654 Ported .view-control SCSS out of tree context to allow more independent use;
Fixes #1654 Significant mods to markup and SCSS;
Fixes #1654 Minor tweaks; class renaming; restructured main containers in ruleTemplate.html; minor updates for class names in WidgetView.js;
Fixes #1654 Merge latest from summary-widgets branch
Fixes #1654 Fixes and tweaks post-merge
Fixes #1654 Add condition duplicate and delete buttons
Merge remote-tracking branch 'origin/summary-widgets-styling' into summary-widgets Apply new style and wire up new markup for interaction
Fixes #1654 Mod .grippy to point at new glyph class; Stubbed in icon palette control in markup;
Add additional implemenation for new markup. Rules now store label and message, and label is applied to widget. Implementation for duplicate.
Issue #1644 Merge and resolve conflicts with style branch Fix rule indexing bug
Fixes #1654 Refactor .l-color-palette to .l-palette, includes file renaming; add icon-palette in WidgetView.js
Issue #1644 Fix merge issue related to inputs for label and message
Issue #1644 Wire up icon palette inputs to widget, and make icon class a persistable property of a rule
Issue #1644 Add implementation and persistability for a single condition configuration field. Baseline for adding arbitrary numbers of rules
Support configuring and persisting multiple conditions per rule
Re-implement widgets in with a module-oriented structure. Fix issues related to asychronous loading of telemetry and composition. Package inputs as re-usable, Zepto-based modules.
Dynamically add value inputs when an operation is being configured. Cleanup code related to removed label caching feature
… rules left, includes some code cleanup
[Summary Widget] Added margin to the delete button (#1762)
…ch for changes unsubscribe on destroy
|
@larkin @VWoeltjen This is implemented using no framework other than Zepto. That's fine, but is this going to be our approach going forward? I think we need to settle on a framework (where 'no framework' is a valid option) before we merge any major new pieces of functionality. |
|
Testing note: There's a lot going on in Summary Widgets, and a lot of it uses observers. It's all fairly self-contained, but still I'd like to make sure that our testing looks out for memory leaks here. |
akhenry
left a comment
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 quality of this code is excellent, and clearly represents a lot of hard work. Well done everyone involved! Apologies if my brief comments sometimes seem curt, I was just trying to keep them succinct, I think the code quality is really high here.
The review contains some issues that I think we should address before merging into master. For other general refactoring issues I've created followup issue #1804
I've also created a couple of other issues for later refactoring once other pieces of API are in place, namely #1801 and #1802. I've also created issue #1803 to address refactoring once we have established post-Angular 1 approach to internal view development.
| var domainObject = legacyObject.useCapability('adapter'); | ||
| var providers = openmct.mainViews.get(domainObject); | ||
| $scope.view = providers[0] && providers[0].view(domainObject); | ||
| /** |
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.
Comment is out of date. A comment is arguably not necessary here at all, it's a small class and the code is pretty self explanatory.
src/plugins/summaryWidget/plugin.js
Outdated
| return { | ||
| name: 'Widget View', | ||
| view: function (domainObject) { | ||
| var summaryWidget = new SummaryWidget(domainObject, openmct); |
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 SummaryWidget conforms to the View interface, we could just return it rather than wrapping it in another object.
| return function install(openmct) { | ||
| openmct.types.addType('summary-widget', widgetType); | ||
| openmct.objectViews.addProvider(initViewProvider(openmct)); | ||
| openmct.legacyExtension('policies', {category: 'composition', |
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.
Formatting of the policy definition could be improved
| <select class="t-trigger"> | ||
| <option value="any">any condition is met</option> | ||
| <option value="all">all conditions are met</option> | ||
| <!-- <option value="js">the following JavaScript evaluates to true</option> --> |
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.
Remove commented code
| </div> | ||
| </span> | ||
| </li> | ||
| <!-- <li class="t-rule-js-condition-input-holder"> |
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.
Remove commented code
| self = this; | ||
|
|
||
| self.telemetryTypesById[object.identifier.key] = {}; | ||
| return telemetryAPI.request(object, {}).then(function (telemetry) { |
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.
Type inference from historical data is not the right approach here, but it's a failing of the API. I've created a separate issue to address this later - #1801
Because this is also populating the subscription cache at the same time I can live with it for now, but at the very least, it should infer type from the value returned by the telemetry formatter's .parse() function, and not from the telemetry datum directly.
| self = this; | ||
|
|
||
| self.telemetryTypesById[object.identifier.key] = {}; | ||
| return telemetryAPI.request(object, {}).then(function (telemetry) { |
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.
Although it's not documented, the request propertiessize: 1 and strategy: 'latest' can be added to historical requests to restrict the amount of data that is brought back to just the most recent datum.
@larkin Since this is quite useful we should document this and make it official (though dependent upon the data store supporting it).
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 could not get this to work, maybe leave this change for v1.1?
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.
They're optional parameters, not all backends will support them (SWG does not, from memory). The request parameters should at least be set though, so that backends that do support them can minimize the amount of data sent back.
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 should be documented. I am pulling out a set of changes from the plot that adds this behavior to all example providers.
| ruleOrder = this.domainObject.configuration.ruleOrder; | ||
|
|
||
| while (Object.keys(this.rulesById).includes('rule' + ruleCount)) { | ||
| ruleCount = ++ruleCount; |
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.
Redundant assignment
| this.domainObject.configuration.ruleOrder = ruleOrder; | ||
| this.updateDomainObject(); | ||
|
|
||
| if(this.editing){ |
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.
We can remove this once the root cause is addressed (see other review comments)
| * Mutate this domain object's configuration with the current local configuration | ||
| */ | ||
| SummaryWidget.prototype.updateDomainObject = function () { | ||
| console.log('persisting'); |
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.
Remove debugging code.
…rsist calls in Rule.js
…go down from 3 to 2. Prevent HTML injection in summary widget labels. Change default name of summary widget to 'Unnamed Rule' to avoid confusion.
…tch for changes unsubscribe on destroy Remove unnecessary persist calls in Rule.js.
82a35cb to
00f4dcd
Compare
…refreshConditions and add it after refreshConditions to initCondition and deleteCondition
…rn summary widget instance in plugin.js instead of wrapping in new object for view
Reviewer Checklist
|
References issues #1644, #1654, and #1669.
Uses new view API implementation from #1642.
Initial pull request for Summary Widgets for Open MCT.
@charlesh88 @larkin Any preliminary feedback appreciated.
Author Checklist