• Home
  • Events
  • About
  • What’s Needed Besides the Presentation Model?

    In the previous chapter we discussed how a simple presentation model framework can substantially reduce the implementation effort for complex user interfaces while at the same time delivering a clean and maintainable software design. However, the presentation model framework is still not sufficient for an efficient implementation of the presentation layer. What else do we need? We can identify the following areas:

    • Attaching user interface components to model properties can be quite cumbersome . Some kind of binding infrastructure takes care of this.
    • Configuring user interface components through a low-level API takes too many lines of code and does not guarantee consistency. A component factory helps to do this with less code and more consistency.
    • Validation can be a tricky beast. Adding validation in the presentation layer is required for better feedback but leads to duplication of business layer validation logic.
    • The design of ergonomic, consistent and visually attractive form-based user interfaces is a challenging task. Furthermore, coding such user interfaces can take way too long without a decent infrastructure.

    Generally speaking, the term “binding” denotes how to keep to properties in sync. In the case of user interfaces one property is hosted by a view component and the other one is exposed by the presentation respectively domain model. As we have seen in our examples this is a two-way sychronization. Without a binding infrastructure you have at least to register an event listener at the user interface component which gets notified about value changes and sets the model property accordingly. Additionally, the user interface component needs to register as an observer to the model property and update the visualization correspondingly. A binding infrastructure can replace multiple lines of code to accomplish the above with a single line of code which is even more expressive and comprehensible. Model properties can be visualized in quite different ways. For example, an integer value could be visualized as a number literal in a text field or as a selection a radio box, check box group, or a combo box. The binding infrastructure should cope with all these variations.
    If user input is not to be immediately commited to the model property the binding infrastructure can buffer these value changes. Finally, the binding infrastructure has to care for value conversions back and forth, e.g. the input field component only accepts strings but the model property is a number.
    For Swing there are several binding infrastructures available: probably the most popular one is JGoodies Binding. JSR 295 is another approach, a reference implementation of which can be found here.

    Component Factory
    The components of common user interface toolkits such as the Swing library expose a large number of properties. Usually, a developer has to configure a component instance to her needs by setting the necessary properties one by one. This not only leads to many lines of code but consistency is also hard to achieve even within the same view. For example, the input field for a customer id should look and behave the same within and across several applications. A component factory both encapsulates the creation and configuration of generic and domain specific user interface components. Even for small projects a component factory is highly recommended.

    Rich Internet Applications do not demand more validation but more frequent validation. With this type of application a user would like to get immediate feedback as he uses the application. The implementation of such fine granular feedback is much more demanding than with a classical web application which gets validated once when submitting the entire form. In order to give immediate feedback, the presentation layer has to validate immediately on user input. Nevertheless, the business layer cannot trust the presentation layer upon validation and therefore it again has to validate all data in its services. Unfortunately, this might lead to code duplication. Clever modularization can factor out the validation code which can the be shared between the presentation and business layer. However, sharing is only possible if you have the same run-time environment for the presentation and business layer. In a scenario where your business logic is implemented in Java and your presentation layer is based on JavaScript you are out of luck and forced to reimplement parts of your validation in JavaScript.
    Basically, there are two types of validation, syntactical and semantical. Syntactical validation should be hosted in the presentation layer in any case, even at the cost of code duplication. You can simply not afford to call a validation service with every user keystroke. Syntactical validation can usually be expressed descriptively and hence it might be sufficient that the business layer just returns a formal description of the validation which is interpreted in the presentation layer. This helps to avoid code duplication. With semantical validation it’s a different story. It is recommended to provide this type of validation as a business service. Semantic validation probably means to access further services or a database. Duplicating this code in the presentation layer is not only expensive but also incurs a performance penality when triggering serveral client-server round-trips. An example for a validation framework for Swing is JGoodies Validation.

    Form Layout
    Designing ergonomic and visually attractive form-based user interfaces is far from trivial. If you have ever tried to achieve this with the basic Swing components and the gridbag layout manager you know what I am talking about. Granted, there are better layout managers, e.g. MiG, JGoodies Forms, the GroupLayout Manager, or the new ULC form component. If you are looking for a comparison of different layout managers, the layout manager showdown has a nice overview. Using these layout managers it is definitely easier to design forms but if you have to implement dozens of densily crowded forms it is still a drag. The problems are efficiency and consistency. Most likely your applications features a few basic form patterns, e.g. a master detail view, search view, etc. Even with an advanced layout manager there is too much design variability for a developer which hampers efficiency and certainly does not lead to a consistent user interface., especially when developing in a team. Therefore, it is recommended to build project (or company) -specific form components which kind of hard-code the layout. This easily pays off with increased development efficiency and user interface consistency. In a recent project we identified the common user interface patterns upfront (we call it meta design) and implemented the necessary form components. As a result, the developers are way more efficient and the user interface of this application (featuring hundreds of form views) is surprisingly consistent.

    The presentation model is indispensible for realizing the complex user interfaces of Rich Internet Applications. It takes very little infrastructure (implemented as a framework), even when extending the presentation model approach with application components for a hierarchical decomposition of complex user interfaces. If you add binding, a component factory, validation and meta design to that your Rich Internet applications will be ahead of those from your competitors with respect to time to market and visual attractiveness.

    Part 1: MVC and the Brave New World of RIA
    Part 2: The World Needs More Models
    Part 3: A Simple View on Complex Stuff
    Part 4: Hierarchies
    Part 5: Presentation Model Framework
    Part 6: What’s Needed Besides the Presentation Model

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Leave a Comment

    Time limit is exhausted. Please reload the CAPTCHA.