Two UIs for rhq-metrics?

[mithomps]

Case for two UI’s

1) Simple rhq-metrics Data Explorer. Easy to understand for anyone. Easily modifiable. No security/roles/login/routes just simple. Almost a dev guide for rhq-metrics but usable as well.

     a) Insert UI for quickly populating a rhq-metrics database with data. Insertion techniques include: Quick Insert, Bulk Insert, Advanced Insert (backfilling data every X minutes for X days), Streaming Insert (stream values every X minutes).

     b) Quickly and easily show graphs of the data using simple graph directives: rhq-directives and/or 3rd party graphing tools. Easily incorporated into other applications.

2) Advanced UI. With all the different visualization things planned things will get complicated so that new users will probably not be able to easily comprehend the UI. Language choice is discussion for later, but possibly Typescript or ES6 (traceur)

     a) Custom graph components (several chart types) ability to drilldown and annotate points/events. This is really the stuff that is talked about in the charter. All the custom graph stuff that is not available in any off the shelf graphing solution. [Essentially, giving data a contextual meaning not just a graph]

     b) Custom Dashboards with templates and linking of multiple metrics

I’m proposing a split where the simple rhq-metrics ‘Data Explorer’ application is where someone new can go and easily start playing with metrics (and even playing with simplistic code). This would be where the current code stays behind.

The Advanced App spilts off into the more sophisticated features using more advanced 3rd party libs, security, custom graph directives and possibly a more advanced javascript variant like Typescript or ES6 Traceur. [Angular 2.0 is already being written using ES6 Traceur.]

From the preceding, it looks like the advanced UI possibly becomes a Hawt.io plugin?

Feedback?

[pilhuhn]

Hey,

Am 11.06.2014 um 07:47 schrieb Mike Thompson <[e-mail]>:

1) Simple rhq-metrics Data Explorer. Easy to understand for anyone. Easily modifiable. No security/roles/login/routes just simple. Almost a dev guide for rhq-metrics but usable as well.

     a) Insert UI for quickly populating a rhq-metrics database with data. Insertion techniques include: Quick Insert, Bulk Insert, Advanced Insert (backfilling data every X minutes for X days), Streaming Insert (stream values every X minutes).

This would be mostly for demo / debugging I guess?

     b) Quickly and easily show graphs of the data using simple graph directives: rhq-directives and/or 3rd party graphing tools. Easily incorporated into other applications.

Absolutely.

2) Advanced UI. With all the different visualization things planned things will get complicated so that new users will probably not be able to easily comprehend the UI. Language choice is discussion for later, but possibly Typescript or ES6 (traceur)

     a) Custom graph components (several chart types) ability to drilldown and annotate points/events. This is really the stuff that is talked about in the charter. All the custom graph stuff that is not available in any off the shelf graphing solution.

Couldn't that be somewhat a general design principle to have a surrounding angular directive that does basic

stuff and then having the possibility to have embedded directives that do the special things.

There is probably a small need for the embedded directives to report stuff back to the outer directive (e.g. values of embedded ones are larger than for the base chart). The embedded directives would then just draw "over" the previous

ones (outer one drawing first - axis after the inner ones have reported their values, then inner ones in element order

of the inner tags).

From the preceding, it looks like the advanced UI possibly becomes a Hawt.io plugin?

As long as it might also work inside UberFire.

Heiko

[lvlcek]

Hi,

just wanted to ask two minor questions:

1. Does it mean you want to maintain two different code bases for two UIs?
2. What specific front-end framework do you consider for this (if any framework at all)? What other technologies/frameworks did you guys consider? If Angular is preferred did you notice Angular 2 is on Google roadmap now? But sadly no one can tell when it will be out, how much it will change and what other features it will get (I was reading through design documents, and I think one of them sums it up nicely when it opens with the following words: "GOAL: For Angular v2.0 we are rethinking everything."). I am asking myself whether I would be able to base any production development on Angular right now, not only because the future API changes are guarantied but also it is quite strong lock-in.

Cheers,

Lukáš

[jastrachan]

Angular 2 isn't here any time soon; hawtio's gonna be using rhq metrics pretty soon on angular 1.x.

Be that as it may; the JS language, HTML5 and CSS isn't really gonna change any time soon; so I'd not worry about some potential changes, some years from now, in how an angular directive is constructed (in the grand scheme of things its a trivial bit of boiler plate wrapper code).

Whats more important is angular 1.x and 2.x is based on the model of web components which eventually all browsers will support one day; namely creating custom HTML5 directives that make web applications composable using HTML / CSS / JS without wrapping things in some massive framework layer. i.e. everything's just HTML really at the page markup level. How a directive is wired together (angular 1.x, 2.x or Web Components/Polyfill is less of a concern really)

I'm not sure where the split is gonna be between the rhq-metrics project and hawtio though; maybe rhq-metrics focusses on the simple, easy to embed/reuse set of views; and the more complex (navigating different resource groups/timelines/profiles/filtering etc) is in hawtio? Am happy for code to move in either direction really

[mithomps]

1. Does it mean you want to maintain two different code bases for two UIs?

The first simple UI is a small amount of code (that is almost complete) and it would just get left behind for the large part as more of a starter project for working with various aspects of rhq-metrics. I suspect a tutorial should accompany the code.

2. What specific front-end framework do you consider for this (if any framework at all)? What other technologies/frameworks did you guys consider? If Angular is preferred did you notice Angular 2 is on Google roadmap now? But sadly no one can tell when it will be out, how much it will change and what other features it will get (I was reading through design documents, and I think one of them sums it up nicely when it opens with the following words: "GOAL: For Angular v2.0 we are rethinking everything."). I am asking myself whether I would be able to base any production development on Angular right now, not only because the future API changes are guarantied but also it is quite strong lock-in.

I suppose there are always concerns with breaking changes in any major release. The Angular 2.0 release is just an umbrella around various angular projects available today (each with varying degrees of completion -- but ones like DI are pretty much comlpete)

The projects are on in the open on github:

angular/di.js · GitHub

angular/watchtower.js · GitHub

angular/expressionist.js · GitHub

angular/assert · GitHub

angular/http · GitHub

angular/deferred · GitHub

angular/diary.js · GitHub

templating/examples at master · angular/templating · GitHub

[mithomps]

The more interesting question is around the huge language changes in javascript ES6. The language changes introduce classes, module loaders, comphrensions, etc...

lukehoban/es6features · GitHub

Bringing javascript much more in line with traditional languages like java. Projects like Angular 2.0 are already using ES6 via translators like Traceur: google/traceur-compiler · GitHub that take ES6 and translate to normal ES5 that runs anywhere. This provides the ability to use ES6 syntax today. Another alternative to use ES6 syntax is Typescript: http://www.typescriptlang.org/ which is also based on ES6 but adds optional type safety.

[lvlcek]

It will be interesting to see how this will go. Personally, I haven't been using Angular. Looking forward to what you guys will be able to do with it (especially implementing complex, maintainable and performant SPA).

Still I think dependency on Angular can be tricky (quite tricky IMO). Things like DI are not based on any ES6 or future ES7 proposal or are they? (you do not need Angular to get the same "DI" in pure JavaScript). Things like diary (and integration with Web Tracing Framework) and deferred have been available in Closure Library for couple of years now (which is pure JavaScript ES5 I think). As for the WebComponents - yes, they are coming, but are they a good fit to build a complex application? See how Angular developers understand that "Build an Angular component to be used in a non-Angular app (ie. Use my-calendar built with Angular inside of an Ember app)" is a goal with the lowest priority for them now, and based on further discussion in that document it seems to me they know it is almost impossible to implement without making Angular even more complex.

Do not take me wrong (and feel free to ignore me - I do not want to be anti Angular hater man). Just wanted to see how other developers think about implementing non-trivial SPAs today. There are a lot of very hard decisions on the way and there does not seem to be a simple answer. In the end of the day Angular can help... who knows.

Cheers, :-)

[pilhuhn]

Am 12.06.2014 um 23:19 schrieb James Strachan <[e-mail]>:

I'm not sure where the split is gonna be between the rhq-metrics project and hawtio though; maybe rhq-metrics focusses on the simple, easy to embed/reuse set of views; and the more complex (navigating different resource groups/timelines/profiles/filtering etc) is in hawtio? Am happy for code to move in either direction really

This is how I think of it right now. Main goal for rhq-metrics(*) is imo the directives to produce charts.

Those directives should also work in other Angular(-capable) environments like UberFire or plain

Angular and thus should not have a dependency on any hawt.io stuff.

We may want/need to have a "showcase" page - like for the current quickstart "dummy-ui", that fills in

some data and then allow interested parties to browse that with the various directives to get an idea

on what they are about.

Heiko

*) On UI side

[jastrachan]

Maybe have a look at the hawtio project; its a complex SPA application thats reactive and all angularjs (using TypeScript which is EcmaScript 6 plus optional type annotations so its got classes and modules).

Its a joy to program in and use and its got tons of great plugins e.g. check out the camel plugin and its the entire fabric8 console.

[lvlcek]

Very nice James,

I will look at hawtio in more detail, it seems interesting (you did a lot of work here). Just three questions (if I may):

1) I noticed it is based on Angular 1.1.5. Do you know how much work it would be to switch to Angular 1.2 or 1.3?

2) I was trying to understand the tests related to SPA layer, is this where I should be looking: hawtio/hawtio-web/src/test at master · hawtio/hawtio · GitHub ? Do you have any idea of how much of the real hawtio web code is covered by those tests? The reason why I am asking about tests is that they are typically the first thing I check when learning new stuff.

3) Which IDE do you recommend to open and develop hawtio source code in? Since it seems to be maven driven is IntelliJ IDEA a good candidate?

Thanks,

Lukáš

[jastrachan]

1) we'll be upgrading to the latest Angular soon; shouldn't be much work as the angular API is pretty stable really

2) to learn Angular I'd start with these lessons:  https://egghead.io/ as there's lots of concepts and techniques you need to get your head around; its not like Java where a JUnit test teaches you about a library (unless you wanna look at the tests of the angular project).

There's some tests here: hawtio/hawtio-web/src/test/specs/spec at master · hawtio/hawtio · GitHub the challenge with hawtio is we typically need to test using hawtio against a distributed system (e.g. fabric8 with a few containers and a message broker etc); so we're hopefully going to create a fuller test coverage project which combines the testing of hawtio and fabric8 soon (which we can run on docker / openstack / openshift to help integration test those too).

3) IntellijJ. hawtio uses TypeScript to generate the JS (which has classes/modules/type inference based on EcmaScript 6) which IDEA has an awesome plugin for.

[kenfinni]

Heiko,

I'm not sure if you're aware of it, but there is the PatternFly Angular project, whose goal is to provide directives, styled with PatternFly, for use with UIs built with AngularJS.

The projected is located at: https://github.com/patternfly/angular-patternfly

It's still very early days for the project, as we're depending on projects determining that they have directives that other projects would find useful.  Currently LiveOak, Keycloak and Aerogear UPS are intending to use these directives, as we migrate existing code to the project.

Ken