Wednesday, March 30, 2011
Wednesday, March 23, 2011
The parts of a user interface should agree in perceived and actual affordances."
(Taken form MIT Courseware)
Tuesday, March 15, 2011
Read more about it here
Friday, March 11, 2011
You want to contribute to the management web interface for JBoss ? Then this should get you going.Codebase
Everything is hosted at github, The best way is to create a fork of either one of the codebases listed below and work on that one.
- Authoritative master: https://github.com/jbossas/console
- Most recent: https://github.com/heiko-braun/as7-console
The console it self is developed using the Google Web Toolkit. You would need to make yourself familiar with the basics before we et going. The GWT SDK will be installed as part of the maven build. No need to fetch it on it's own. If you plan to work with Eclipse, then you should consider the development tools for GWT that are provided by Google. But please don't ask how things are setup correctly in Eclipse. We baseline on maven and that's it.
Things you need to know
We build on GWT 2.2 without any dependencies on external widget libraries. However these is a growing number of widgets (org.jboss.as.console.client.widgets) that should be reused. We aim for keeping the overall number of widgets to a minimum.
But if you need anything that doesn't exist, take a look at the SmartGWT showcase, tell us about it and we'll then consider implementing it.
But one of the cornerstones is the GWT Platform library, which nicely abstracts the MVP pattern. It act's as a blueprint for the console design. A good introduction can be found here. (This is a "must read")
Internal model representations are build as AutoBean's. They align well with the default GWT API and have build-in serialization support. A general guideline: Any domain representation that's used within the console needs to be provided as an AutoBean abstraction. This means that beyond the integration layer (backend calls to the AS 7 domain) entities need to be adopted.
This is necessary to provide a baseline for the data binding used across widgets. Take a look at the form abstractions, then you'll know what I mean. The CellList and CellTable API's are another example.
We are using the AS7 mailing lists and/or IRC for discussions of technical matters, improvements, proposed patches, etc:
Thursday, March 10, 2011
Deployments (associated with server group)
Server Configuration (on a host)
Server Instances (on a host)
Conceptually the domain model consists of three different levels, that we tried to reflect within the user interface: Configuration profiles, server groups and host specific settings.
If you think of these levels as being layered atop of each other, then Profiles would be the bottom most configuration level that acts as a blueprint for the layers atop of it. Profiles consist of subsystem specific settings (i.e. JCA, TX, etc) and are referenced by Server Groups.
Server Groups on the other hand specify configuration properties for a set of Servers that run on different Hosts.
A Host is the top most and most detailed level. It runs Server Instances that belong to a particular Server Group.
While there are numerous ways to organize the information accessible through the web interface, we used a few simple questions to guide our decisions: