incubator-kalumet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré>
Subject RE: WebApp framework replacement for Kalumet
Date Sun, 28 Dec 2014 11:27:29 GMT
Hi Randall

Merry Christmas to you and your family.
And thanks for your update. I'm on road today, I will get back to you tomorrow.


Sent from my Samsung Galaxy smartphone.

-------- Original message --------
From: "Dietz, Randall" <> 
Date:28/12/2014  09:08  (GMT+01:00) 
Subject: WebApp framework replacement for Kalumet 

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

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






The key factors I was looking for were:


   Compatibility with Apache – in particular, conforming to the Apache

   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

   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

   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

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

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
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message