-
Notifications
You must be signed in to change notification settings - Fork 17
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
Add CumulativeFlow #35
base: master
Are you sure you want to change the base?
Conversation
Hi @ptomli ! As you've already noticed, manually hacking the dashboards DOM to add a chart is too messy. What's more important is that this approach is too fragile—we have no obligations in preserving the DOM structure the same in the subsequent releases, and thus we can't guarantee that mashups written this way wouldn't break at some point. Fortunately, there is a much cleaner and stable way to create a new widget via the dashboards API (please note that it's not officially published yet, but we use it internally for all widgets ourselves, so you may expect it to be quite stable). Basically, the dashboard extension comes down to 2 steps:
Define a widget templateThe most basic widget template is an object with a string
Register your widget templateWidget gallery is a collection of all widgets available in Targetprocess. It is the primary tool for users to discover and add widgets to their dashboards. Unlike the machines, the regular users, are not so good at operating the unique template IDs. To make their lives easier you should add user-friendly information to your widget template to make it easier to find in a widget gallery. You may extend the previously defined template with
To let the application know about your new widget template and to make it available in a widget gallery for the end users, you need to register it in a widget template registry.
Putting it all togetherThe final mashup module now should look like this
Also it looks like What's nextThere are some other great things which you can do with that API. So would you be willing to try this API? I'd love to hear your feedback, and we will be able to merge it into mashups library if it works great. |
@khmylov thanks for that, it looks quite possible to improve quite a bit on the code I have so far. I'll have a look and see what I can come up with |
@khmylov is there some documentation for the API? Particularly the second argument, |
@ptomli Like I said, it's not officially published yet, but here's the excerpt of what we have documented for now: https://gist.github.com/khmylov/f0c3e774735d9de80cea. It should cover everything related to widget integration, but feel free to ask if you stumble into any issues. |
@khmylov I've been looking to see if tauCharts would be a suitable replacement for highcharts, on the basis that it's likely already integrated in some form into TP. However, I can't see that tauCharts can produce a stacked chart natively, so I'd have to produce the stacked data myself. Any suggestions? Also, I think I've determined that the settings storage doesn't seem to support some objects, in this case specifically a Date instance. Can you confirm this, and other limitations thereof? Are settings expected to be stored in a single, non-nested object, with string properties? |
@ptomli Dashboards use our "client storage" underneath, so the settings object goes through
Concerning the tauCharts: I'll ask @Mavrin to help you, he's got much more expertise here :) |
Hi @ptomli , Unfortunately tauCharts doesn't support area and stacked bar charts now. We will implement these chart types in the near future. |
Hey @ptomli, do you need any help with making CFD work with dashboards API? |
Thanks @khmylov, I've not had a chance to look at it for a few days, but I was getting to grips with trying to present the settings inputs. It seemed somewhat verbose, manually creating inputs and such, so I didn't progress much further yet. Pity there isn't some API to allow a widget to provide a structure detailing the settings UI needed, and TP deals with generating as needed.
I'm sure that wouldn't cover all requirements for all widgets, but I imagine it would make most widgets easier to write. So, that's where I am. Not wanting to write lots of lines of verbose DOM manipulation code, not wanting to learn React (simply to render a few inputs). I'll make the WIP available when I'm back in the office on Monday |
A somewhat useful mashup to display a CFD