“Red Hat JBoss BRMS and BPMS Workbench and Rich Client Technology”
The presentation highlighted the wider scope of our UI efforts; demonstrating what we’ve done within the BRMS and BPMS platform and the flexibility and adaptability provided by our UI technology. It provides a great testimony for the power of GWT, Errai and UberFire, the three technologies driving all of this. We can’t wait for the GWT 2.7 upgrade 🙂
As mentioned in the last blog the UberFire website is just a placeholder and there is no release yet. The plan is first to publish our 0.5 release, but that is more for our BRMS and BPMS platforms. We will then move it to GWT 2.7 and work towards a UF 1.0, which will be suitable for wider consumption. With 1.0 we will add examples and documentation and work on making things more easily understood and consumable for end users. Of course there is nothing to stop the adventurous trying 0.5, the code is robust and already productized within BRMS and BPMS – we are always on irc to help, Freenode #uberfire.
That presentation itself built on the early video’s showing our new Apps framework:
The Drools and jBPM KIE Apps Framework
The above video already demonstrates our polyglot capabilities, building AngularJS components and using them within the UF environments. It also shows of our spiffy new JSFiddle inspired RAD environment.
I’d now like to share with you the work we’ve done on the other side of polyglot development – this time using GWT and UF from within AngularJS. It was important we allow for an AngularJS first approach, that worked with the tool chain that AngularJS people are familiar with. By AngularJS first, I mean that AngularJS is the outer most container. Where as in the above video UF is already running and is the outer container in which individual AngularJS components can be used.
Before I detail the work we’ve done it’s first best to cover the concepts of Screens and Perspectives, our two main components that provide our polyglot interoprability – there are others, but this is enough to understand the videos and examples that come next. A Screen is our simplest component, it is a DIV plus optional life cycle callbacks. A Perspective is also a DIV, but it contains a composition of 1..n Screen with different possible layout managers and persistence of the layout.
- CDI discovery, or programmatically registered.
- DIV on a page.
- Life cycle callbacks.
- OnStart, OnClose, OnFocus, OnLostFocus, OnMayClose, OnReveal.
- Decoupling via Errai Bus.
- Components do not invoke each other, all communication handled by a bus.
- Editors extend screens, are associated with resource types and provide the additional life cycles
- onSave, isDirty.
- CDI discovery, or programmatically registered.
- Composition of 1..n Screens, but is itself a DIV.
- Supports pluggable window management of Screens.
- North, East, South West (NESW).
- Drag and Drop docking capabilities.
- Bootstrap Grid Views.
- Separate design time and runtime.
- Templates (ErraiUI or AngularJS).
- Absolute control of Perspective content and layout.
- Supports persistence of Perspective layout, should the user re-design it.
- Only applicable to NESW and Bootstrap Grid views.
A picture is worth a thousands words, so here is a screenshot of the Perspective Builder in action. Here it uses the Bootstrap Grid View layout manager. Within each grid cell is a Screen. The Perspective is saved and then available from within the application. If the NESW layout manager was used there is no separate design time, and all dragging is done in-place and persistence happens in the background after each change. Although it’s not shown in the screenshot below we also support both list (drop list) and tab stacks for Screens.
Now back to what an AngularJS first approach means. 6 different points were identified as necessary to demonstrate that this is possible.
- UF Screens and Perspectives should be available seamlessly as AngularJS Directives.
- Bower packaging for a pre-compiled UFJS. UFJS is the pre-compile client only version of UF.
- UFJS can work standalone, file:// for example. UFJS can optionally work with an UF war backend, allowing persistence of perspectives and other optional places that UFJS might need to save state as well as access to our full range of provided services, like identity management.
- Support live refresh during development.
- Nested Controllers.
- Persistence and routing.
- Work with tools such as Yeoman, Grunt and Karma.
Eder has produced a number of examples, that you can run yourself. These demonstrate all of the points have been solved. You can find the code here, along with the README to get you started. We did not provide video’s for point 7, as I believe the video’s for points 1 to 6 show that this would not be a problem.
Eder has also created several short videos running the examples, for each of the use cases, and put them into a YouTube playlist. He has added text and callouts to make it clear what’s going on:
AngularJS + UF PlayList
- Overview explaining what each video demonstrates (33s).
- AngularJS App + UFJS, client only, distribution using Bower. (2m30s).
- Install and play with UFJS through Bower
- Create a Native AngularJS App
- Integrate this app with UFJS
- Show UF Screen Directives
- Show UF Perspective Directives
- 1 of 2 (3m58s).
- Download UF War
- Install and run on EAP
- Download and run our Angular demo on Apache
- Show AngularJS Routes + UF Integration
- 2 of 2 (4m06s).
- Use UF to create Dynamic Screens and Perspectives
- Encapsulate an AngularJS template in a UF Screen
- Show an AngularJS App (inside a UF screen) nested in a parent controller.
- Demonstrated multiple levels of controller nesting.
For completeness the original video’s showing the JSFiddle inspired RAD environment, which demonstrates an UF first polyglot environment, have been added to the playlist. See point 4. above
Finally just to show of, and because we can, we added a bonus video demonstrating a UF editor component running seamlessly in Eclipse. This demonstrates the power of our component model – which has been designed to allow our components to work standalone in any environment. We use Errai to intercept all the RPC calls and bridge them to Eclipse. Because the virtual file system our editors use, like other services, is decoupled and abstracted we can adapt it to the Eclipse File io. For the end user the result is a seamless editor, that appears native. This allows the development of components that can work on the web and in Eclipse, or even IntelliJ. We’ll work on making this example public at a later date.
Here are some screenshots taken from the video’s
Finally to all those that said it couldn’t be done!!!!