Product Reviews

Digg This!

Page 1 of 3   next page »

The Java development platform always provides limited support for application development based on a graphical user interface, an area where more traditional languages and integrated development environments (IDEs) such as Visual Basic or Delphi have based their success.

Today the Java SE distribution offers essentially the same features it offered in 1999 with regards to Java graphical components: the Swing toolkit. Swing provides graphical components like grids, trees, text fields, checkbox, radio button, combo-box and others. Anyway these components have changed little and not been improved in latest releases of Java. All in all Swing greatly lacks some key aspects:

• Input fields are too simple. They can't be compared with the advanced graphical components available in other languages. They don't support common properties like text trim, padding, text length checking, uppercase; moreover there's no numeric field, currency field, date control or calendar control. There's no relationship between the input field and internationalization settings.

In addition, Swing components are just hard to use. For example, creating a powerful table with editing capabilities, colors, data formatting, column or row locking usually requires a lot of code, time, and skills. A more powerful and easier set of components is needed to develop rich GUIs, especially for beginner Swing programmers.
• There's no binding mechanism between graphical components and the data model. This means that to set or get data from or to a data model based on POJOs (Plain Object Java Object, i.e., Java Beans) requires additional coding, not provided by the Swing toolkit.
• There's no data retrieval layer between the presentation tier and business logic/data access layers that facilitates and normalizes data exchange with the presentation tier and other layers.

All these deficiencies don't encourage the development of enterprise applications with rich GUI content and based only on the Swing toolkit.

This gap in Java was partly covered in the past years, thanks to solutions supplied by the market in the shape of commercial and open source solutions, but without reaching any definition of a reference standard.

Commercial solutions should be discarded because they're proprietary, not directed by the market, and in plain disagreement with the "Java philosophy" of open source solutions or solutions supported and promoted by the market, led through mechanisms of sharing and the collective definition of standards such as JCP (the Java Community Process).

With regard to open source solutions, there are several Swing extensions, born to provide:

• a suite of advanced graphics components
• a binding layer between graphics controls and data model
• a framework that defines guidelines to design an application and its components and use these components correctly
• a data retrieval mechanism that (preferably) abstracts from the real location of the data (locally or remotely)

There are many free solutions available that meet some of these topics, such as JMatter, JGoodies, JDNC (Java Desktop Network Components) and its evolution, the Swing Application Framework, currently submitted for approval to JCP. There are other open source projects that fit specific issues, as those reported on the JavaDesktop portal.

However these solutions address some issues (like the availability of advanced graphics controls or data binding capability) but not all the issues that could arise in enterprise application development with rich GUI content and not always applicable on different architectures (both two- and three-tier applications, with data communications based on HTTP or SOAP or RMI or any other protocol).

A good solution should include the capacity to decouple GUI development from data retrieval issues: this could facilitate application development with several architectures, such as two-layered applications (desktop applications) and three-layered applications (Rich Internet Applications). This way the same suite of graphics components and data binding mechanisms could be reused in different application architectures.

Broadly, there's a need for a complete solution: a framework (i.e., a set of development guidelines) and a set of advanced Swing components with data binding capabilities and data retrieval mechanisms not limited to a specific architecture to develop applications having rich GUI contents quickly and easily.

RIA development would become one of the possible scenarios that issues from that solution.

A complete client-side solution should integrate all these aspects and ideally fit with existing server-side layers and frameworks: in the context of server-side development, especially in the context of Web application development, valid frameworks already exist such as Spring and effective ORM (Object to Relational Mapping) layers like Hibernate, iBatis, TopLink, JDO, and JPA; hence, it's unnecessary to develop other server-side frameworks. It's better to interconnect them with the complete client-side solution.

To realize this kind of client-side solution, it's possible to fit more client-side products together, such as some of those described above, but this attempt requires skills in many products and a lot of time and isn't a suitable choice for organizations with low skills levels and limited budgets.

The OpenSwing framework addresses these issues by providing a unique and uniform client-side solution: it provides a suite of advanced graphics components that are usually powerful enough that they don't have to be extended any further. They meet the development requirements of enterprise applications with rich GUI contents. The development process becomes easier and faster by developing a GUI through IDEs' graphical designers like other non-Java RAD environments.

At the same time, this framework provides other software layers that complement the OpenSwing graphics components suite by supporting data binding, POJO-based data modelling, and remote data access by allowing the development of RIAs (three-layered client/server applications) or desktop applications (two-layered client/server applications).

OpenSwing
OpenSwing is an open source framework that can be used to develop Java applications based on Swing's front-end.

It's possible to apply this framework to develop two-tier client/server applications with an underlying database or based on other data storage devices (like files on a file system) or three-tier applications with several combinations of technologies such as RIAs (where the client and server tiers communicate through the HTTP protocol) or distributed applications (where the client and server tiers communicate through RMI - see Figures 1, 2, and 3).

The framework includes a set of class libraries that can be used to:
• Create the application front-end through a collection of advanced graphics controls that include labels, text fields, multi-line text fields, numeric fields, currency fields, calendar, grid, trees, a tree combined with a grid, lookup, gantt diagram, buttons with images, combo-box, radio buttons, checkbox, wizard panel, image panel, splash screen, dialog windows, tip of the day frame, progress bar/panel/dialog, and a licence agreement panel.

Grid usage is especially sophisticated: it allows columns or rows locking, data pagination, columns filtering and sorting, and data exporting and the grid model is based on a list of POJOs like a tree component and a panel of graphics controls whose data model is based on a POJO.

So POJO support is extended to the entire set of graphical components that compose the GUI.

Page 1 of 3   next page »