The Graphical User Interface (GUI) is built as a stand alone application that talks to the Server via RESTful API on the server side, such that UI work and business logic are insulated from each other.
All integration between the database and server would be via web services. Both XML and JSON are acceptable, as is any other pure text format that we care to use.
Web services then become the gateway to the system,
The reasons I am driving this approach are:
- Server side generation of GUI code slows down development due to the need to deploy new code. Server side generation of GUI causes tight coupling between the GUI and the Business logic, making it tough to use the same code to support both a rich gui and a Command Line Interface (CLI)
- Server side generation of GUI limits us to the set of widgets that come with the toolkit, effectively tying the hands of the User Experience Design (UXD) team.
- We can grow a team of UI developers that are agnostic of the Java vs LAMP divide so prevalent in the web world.
- We can develop a richer UI experience that is more consistant across multiple projects, regardless of the server side language.
Far more likely is that an application like this will start out strictly CRUD like and will morph into something requireing more business logic over time. Keeping the UI and the business logic separated by machines may actually simplify the refactoring and evolution process, but it shouldn’t make it any more complicated than if the whole thing were done as server side scripting in the first place.
Internationalisation (I18N) : Java has very strong support for message bundles as part of the internationalisation process. Thus, creating a web that supports multiple languagesis a “simple” as using token replacements instad of straight text, and providing message.properties files for each of the languages you want to support.
Ideally, the I18N code would itself be dynamic. Facebook has shown how quickly a site can evolve if you delegate the translation to the end users. While this might not be acceptable or appropriate for an app deployed in a more controlled manner, it still makes sense to separate the deployment of new text bundles from your general QA process, as the two processes are quite separate. Ideally, people can be working on language support that can be deployed on their own schedule, dependant only on the current set of I18N tokens in the web page.