WebApp framework replacement for Kalumet

["Dietz, Randall" <ra...@dietz.id.au>]

Hi all,

And a Merry Xmas...

I have spent several days looking at options for refactoring the Kalumet
Console from echo2 to a new framework. I submit my findings for your
consideration.

In summary, I am recommending the use of Vaadin as an echo replacement.

I reviewed a number of webapp frameworks, including:

   -

   Apache Tapestry
   -

   Apache Wicket
   -

   Vaadin
   -

   AngularJS
   -

   Struts2
   -

   Spring
   -

   Play

The key factors I was looking for were:

   -

   Compatibility with Apache – in particular, conforming to the Apache
   licensing.
   -

   Developer efficiency – the ability to quickly produce a UI
   -

   Minimal learning curve – how well was the framework documented and
   supported? Was I able to produce reasonable results after following
   tutorials?
   -

   Minimal reliance on creating HTML – following the echo2 paradigm of
   generating the UI from Java.
   -

   Testability – the ability to create unit tests around the UI logic

Many of the players were discounted early due to licensing or high
complexity.  I did not intend to go into great detail on why a particular
framework was discounted, but if someone has a particular framework that
they prefer over my recommendation, I could provide more in-depth analysis.

Some of the key points influencing my recommendation include:

   -

   Apache 2 licensing
   -

   Compatibility with existing Kalumet Maven project
   -

   UI generated from Java classes, with support for complex web pages if
   necessary.
   -

   Good support for UI unit testing.
   -

   XXXXAn active community
   -

   Support for persistence libraries like Hibernate and H2
   -

   The documentation is complete, although somewhat difficult to wade
   through...

I have spent a couple of hours modifying one of their prototype projects to
demonstrate how the console could look. Note that the intent here is to
show the basic Vaadin look and feel... it is not complete (only
environments and about semi-functional) and I have not spent a lot of time
trying to make it look pretty.  Nor have I bothered with adding the Apache
licensing throughout... I'll wait until there is agreement on the way
forward

I would suggest that refactoring the console would be a good opportunity to
review the current UI in light of more industry-accepted UI behaviour to
produce a consistent look and feel that will be easier for end users to
use. I have uploaded the WAR to
https://www.dropbox.com/s/afza9cqm6e9ifzp/kalumet-console2-1.0-SNAPSHOT.war?dl=0
for
your consideration.

My suggestion for next steps are:

   -

   Agreement on the framework – I can work with Vaadin and I believe it
   will be one of the more easily supported options moving forward, but I'm
   happy to field any queries or preferences anyone may have.
   -

   Once we agree on a framework, we need to get agreement on the UI... in
   particular, does the new console need to look exactly the same as the old
   one, or do we have a bit of leeway to produce a more consistent and
   friendly look and feel?
    -

      I am willing to prototype a complete set of non-functional screens
      that conform to Vaadin (or other framework) best practices for
      consideration by other project developers.
      -

      Create a Jira task to refactor the console and assign it to me (or
      proxy through another project member).
      -

      I will submit the resulting code for the prototype to the project for
      consideration in regards to design.
       -

   If it all looks like a reasonable approach, implement the console in the
   new framework.
    -

      At first glance, I believe there will be minimal impact to the
      Kalumet code base as there is a fairly reasonable separation of
the console
      code from the other Kalumet functionality.

I still have some holiday time that I can devote to this, so if we are able
to progress this soon, I can devote some more time to it before I go back
to work...

Regards – Randall