From kalumet-dev-return-480-apmail-incubator-kalumet-dev-archive=incubator.apache.org@incubator.apache.org Sun Dec 28 08:10:44 2014 Return-Path: X-Original-To: apmail-incubator-kalumet-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-kalumet-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 14017100C5 for ; Sun, 28 Dec 2014 08:10:43 +0000 (UTC) Received: (qmail 9255 invoked by uid 500); 28 Dec 2014 08:10:42 -0000 Delivered-To: apmail-incubator-kalumet-dev-archive@incubator.apache.org Received: (qmail 9227 invoked by uid 500); 28 Dec 2014 08:10:42 -0000 Mailing-List: contact kalumet-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: kalumet-dev@incubator.apache.org Delivered-To: mailing list kalumet-dev@incubator.apache.org Received: (qmail 9210 invoked by uid 99); 28 Dec 2014 08:10:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Dec 2014 08:10:40 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: local policy) Received: from [209.85.220.180] (HELO mail-vc0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Dec 2014 08:10:34 +0000 Received: by mail-vc0-f180.google.com with SMTP id im6so4430020vcb.25 for ; Sun, 28 Dec 2014 00:08:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=jgrHodSmMkGnZI3OgqDHWAD+tip3aM5Ah//bvNHtib4=; b=DEaMiOwyRlWuwf2XUMpcSj21pCoYTpWl9gsJBy4sEEAzMvm7lltB6Q6y2fIdcPrmxY H49tu63d+MwGucXOEyf0sKYIR1JYDRpHvqWqkk1dow0IjkNa+E27CcHu9VXhIqnsxoDu uW33d0T7q1HVaj5JR0LfIxHoU81VZuzGEdH77q1bYnxNwZJRgDBYWKzfQxE5nQ9RIyup f8LXSdLT9MMfP4Ku9hLq1C3J3XXrwu8/YktdFcHpVoUtyCSSOrfF5qrpoRHfRkQGp1cF mpIeWc2GO0ZWviQ7N7GqBGdjqvlr6Yi/IZTMTxiI6b78T7rmi9oqTpIaubp7ZHisoaeC caQA== X-Gm-Message-State: ALoCoQlj2+qtS0HpH+XqL9EQFWMJ8yzn3fycQyv4bygXI6tAvB77m4CxuBArgxQxGsT0YKm7E037 X-Received: by 10.220.139.135 with SMTP id e7mr27228205vcu.75.1419754101114; Sun, 28 Dec 2014 00:08:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.189.195 with HTTP; Sun, 28 Dec 2014 00:08:00 -0800 (PST) X-Originating-IP: [58.165.233.172] From: "Dietz, Randall" Date: Sun, 28 Dec 2014 18:08:00 +1000 Message-ID: Subject: WebApp framework replacement for Kalumet To: kalumet-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=047d7b343306dd9d9c050b424236 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b343306dd9d9c050b424236 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=93 in particular, conforming to the Apa= che licensing. - Developer efficiency =E2=80=93 the ability to quickly produce a UI - Minimal learning curve =E2=80=93 how well was the framework documented a= nd supported? Was I able to produce reasonable results after following tutorials? - Minimal reliance on creating HTML =E2=80=93 following the echo2 paradigm= of generating the UI from Java. - Testability =E2=80=93 the ability to create unit tests around the UI log= ic 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=3D0 for your consideration. My suggestion for next steps are: - Agreement on the framework =E2=80=93 I can work with Vaadin and I believ= e 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 ol= d 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 =E2=80=93 Randall --047d7b343306dd9d9c050b424236--