5 Replies Latest reply on Jun 18, 2014 12:33 AM by jastrachan

Charting Tag API

mithomps Jun 3, 2014 11:35 AM

As a starting point to discussing the metrics charting, one of the basic components of this, is the chart. This is a draft of the angular charting directive (tag). Most important here are the attributes and the naming conventions (so that we don't have a bunch of projects with all different looking tags).

[The required attributes are in bold, all other attributes are optional and have defaults. Most of the attributes are optional and exist due to i18n.]

<rhq-metrics-stacked-bar-chart

rhq-data="{{chartData.dataPoints}}"

rhq-yaxis-units=""

rhq-chart-title="{{title.name}}"

rhq-chart-height="250"

rhq-chart-hover-date-format="%m/%d/%y"

rhq-chart-hover-time-format="%I:%M:%S %p"

rhq-time-label="Time"

rhq-date-label="Date"

rhq-buttonbar-datetime-format="MM/DD/YYYY h:mm a"

rhq-single-value-label="Raw Value"

rhq-no-data-label="No Data"

rhq-aggregate-label="Aggregate"

rhq-start-label="Start"

rhq-end-label="End"

rhq-duration-label="Duration"

rhq-min-label="Min"

rhq-max-label="Max"

rhq-avg-label="Avg"

rhq-avg-line-color="darkblue"

rhq-high-bar-color="steelblue"

rhq-avg-bar-color="lightblue"

rhq-low-bar-color="lightgray"

rhq-on-focus-date-change="handleDateChange">

</rhq-metrics-stacked-bar-chart>

Components will be documented with ngdoc (based on jsdoc) and will follow any Red Hat angular component standards as set by: patternfly/angular-patternfly · GitHub

Anything I left out?

1. Re: Charting Tag API

heiko.braun Jun 4, 2014 1:00 AM (in response to mithomps)

I would suggest to remove the rhq prefix thats spread all over the place. Its very verbose and doesnt improve readability.

Am 03.06.2014 um 17:35 schrieb Mike Thompson <do-not-reply@jboss.com>:

JBoss Community
Charting Tag API
created by Mike Thompson in rhq-metrics - View the full discussion

As a starting point to discussing the metrics charting, one of the basic components of this, is the chart. This is a draft of the angular charting directive (tag). Most important here are the attributes and the naming conventions (so that we don't have a bunch of projects with all different looking tags).

<rhq-metrics-stacked-bar-chart

            rhq-data="{{chartData.dataPoints}}"

             rhq-yaxis-units=""

             rhq-chart-title="{{title.name}}"

             rhq-chart-height="250"

             rhq-chart-hover-date-format="%m/%d/%y"

             rhq-chart-hover-time-format="%I:%M:%S %p"

             rhq-time-label="Time"

             rhq-date-label="Date"

             rhq-buttonbar-datetime-format="MM/DD/YYYY h:mm a"

             rhq-single-value-label="Raw Value"

             rhq-no-data-label="No Data"

             rhq-aggregate-label="Aggregate"

             rhq-start-label="Start"

             rhq-end-label="End"

             rhq-duration-label="Duration"

             rhq-min-label="Min"

             rhq-max-label="Max"

             rhq-avg-label="Avg"

             rhq-avg-line-color="darkblue"

             rhq-high-bar-color="steelblue"

             rhq-avg-bar-color="lightblue"

             rhq-low-bar-color="lightgray"

             rhq-on-focus-date-change="handleDateChange">

        </rhq-metrics-stacked-bar-chart>

Components will be documented with ngdoc (based on jsdoc) and will follow any Red Hat angular component standards as set by: patternfly/angular-patternfly · GitHub

Anything I left out?

Reply to this message by going to Community
Start a new discussion in rhq-metrics at Community
Following rhq-metrics in these streams: Email Watches
Actions
2. Re: Charting Tag API

theute Jun 4, 2014 5:30 AM (in response to heiko.braun)

I would suggest to remove the rhq prefix thats spread all over the place. Its very verbose and doesnt improve readability.
+1 at least from the attributes names. (For the tag name we may want to keep a prefix/namespace, but maybe we could shrink to "rhqm")

I am unsure about the "chart" word, don't all the attributes relate to the chart ?
Actions
3. Re: Charting Tag API

pilhuhn Jun 4, 2014 7:12 AM (in response to theute)

+1 on what Thomas said.
Actions
4. Re: Charting Tag API

mithomps Jun 4, 2014 10:10 AM (in response to theute)

I agree it does add verbosity. This seems to be the angular practice within Red Hat to prepend the project initials to the attributes in this manner. It becomes useful for example, when you have a customized button directive and you are able to tell which are the custom attributes and which are the base button attributes. Also, directives can be applied to any html tag so its not apparent that it is a custom attribute unless it has a prefix.
Example:
<input type="number" required parse-special />
It's not easily understandable that required is a standard html5 attribute and that parse-special is defined by my directive.

[In the strictest sense, custom attributes should all have the 'data-' to pass html5 parsing rules]

For brevity, I will remove the rhq- prefix from the attributes.
Actions
5. Re: Charting Tag API

jastrachan Jun 18, 2014 12:33 AM (in response to mithomps)

if a directive is just a new attribute on an existing element (e.g. <button>) then use the prefix; but when the directive is a new element (with a project-specific prefix) I'd say there's no need to use a prefix for the attributes too.

One of the main reasons for all the "ng-" prefixes in the common angular directives is they are new attributes on existing HTML elements (e.g. on <input>)
Actions

Go to original post