• Home
  • Events
  • About
  • Presentation Model Framework

    September 19th, 2008

    In the previous chapter we looked at the implementation of a non-trivial application composed of several application components. If you had a closer look at the code fragments in chapter 3 you probably realized that even for a simple application component quite some boiler plate code was required to make it work. The presentation model contains infrastructure code that takes care of property listener handling, e.g. registering property change listeners and distributing property changes to listeners. It also has to delegate most property requests to the business object. These tasks can easily be extracted into a base class and handled generically.
    In addition, the base class can provide infrastructure such as:

    • Creation, proper initialization, and management of a hierarchy of application components: the root application component is responsible for property change listener management, i. e. all sub-application components delegate to the root application component rather than managing this all over the hierarchy, which simpifies debugging a lot.
    • Breaking cycles: the execution of a property change listener should not trigger (directly or indirectly) the same property change listener.
    • Undo/Redo support: The presentation model is a Java bean and all state transitions are performed by property changes. Hence, undo/redo support is really easy to implement on a generic basis. The abstract presentation model just records all property changes and can undo or redo them on request.

    This leads to a simple presentation model framework with only a few hundred lines of code. It is independent of any widget library, although the current implementation includes configurable table and tree models based on the ULC widget library. They should be easily replaceable by model implementations of some other component library.

    The view code is even more cumbersome. Despite being pretty straightforward way too many lines of code are needed for implementing the view. How can this be simplified?

    • Creating the layout can be accomplished by using either a declarative or programmatic approach. For the declarative approach one would need some XML schema for defining the components and layout of the user interface. At run-time, an interpreter creates the UI based on the XML description. The programmatic approach requires at least a layout class which is tailored to form-based user interfaces. Examples are JGoodies Forms or the new form infrastructure in UltraLightClient ’08.
    • Connecting the widgets to the presentation model and vice versa can be vastly simplified by utilizing some binding infrastructure. We will talk about binding in the next chapter.
    • The remaining tasks are easy to implement and require little code: proper initialization of the view (most initializations are triggered by the presentation model anyway), forwarding events to the presentation model that are not yet taken care of by the binding infrastructure (e.g. button actions), and reacting to changes in the presentation model (e.g. enabling/disabling portions of the user interface accordingly).

    Now lets have a look at the code for the example from chapter 3. For the programmatic layout of the form I used a simple form layout class.

    The core code for the presentation model looks almost like the example given in chapter 3 (boiled down to three model properties for the sake of simplicity). Thanks to the presentation model framework, the number of lines of code is cut almost in half (now less than 150 lines of code incl. comments and blank lines).

    Some functionality is based on conventions which can be customized by overriding the appropriate methods. Properties are “exported” by declaring the path as a string constant, e.g. PERSON_NAME. The business object is referenced by an instance variable. The prefixes of the property constant names are kept in the string array PREFIXES. This way, properties can easily be retrieved by reflection. This is used to fire property change events or register event listeners for all properties.

    Theview class is also reduced to half the lines of code. This is mainly due to the form layout class and the binding infrastructure.

    Now, what does it take to add undo/redo to this example? As mentioned before, the abstract base class for the presentation model already contains generic undo/redo support. All we have to do is offering undo or redo in the user interface. I simply had to add two additional buttons for that, which call undo resp. redo on the presentation model. In addition, the view has to enable or disable the undo/redo buttons if undo/redo is possible or not. The abstract presentation model triggers this event conveniently. The extensions to the presentation model are minimal. It has to reset undo/redo when loading or saving the business object and it sets the focus in the view to the component which was affected by undo/redo.

    How does the presentation model fit into an application which needs to render live data. Actually, the presentation model can also handle this scenario quite nicely. There is only one issue to consider. The data feed can be considered as yet another model which the presentation model can subscribe to. Thereby the presentation model is notified about any relevant model changes. However, these model events most likely occur outside of the UI event thread (e.g. posted by some server) and therefore they cannot be processed synchronously by the presentation model which runs in the UI event thread. The solution is quite simple. The presentation model stores these events in a queue which is processed prior to the next event that occurs in the event thread, i.e. the next event that is going to be processed synchronously. While processing the asynchronous model events the undo/redo recording has to be temporarily suspended since these events are not created by the user and therefore undo/redo is pointless.

    The presentation model framework is available Presentation Model Framework. It solves many design issues in rich user interfaces and also helps developers to focus on implementing cool and ergonomic user interfaces rather than dealing with design and infrastructure issues. The framework is also independent of the user interface component library. The only exception are the table and tree model adapter classes which are specific to the ULC component library. It should be pretty simple to replace them with an implementation for the user interface component library of your own liking. Also included in the download are a number of examples which demonstrate how to use the presentation model framework. These examples were implemented with the ULC component library. In order to compile and run them you also need to download the ULC component library. You can get a free evaluation license for ULC here. Additionally, the examples need some infrastructure code (e.g. binding, form layout and validation support) which comes with the download. This infrastructure code has been extracted from a larger project and stripped down to minimize dependencies. Hence, they do not really serve as an example.

    In the last chapter we will have a look at additional infrastructure which even more simplifies implementing rich user interfaces.

    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

    Save Time and Money (Part 3)

    September 19th, 2008

    In this blog post series, I am revisiting some of the arguments in favor of a Java-based RIA library such as UltraLightClient. Please leave a comment and share your views. See Part 1 and Part 2.

    Why ULC (Part 3)

    I’ll spare you the typical marketing speak about how we believe Canoo’s UltraLightClient will save you real money in terms of time for development and maintenance. Instead I’ll quote from an email that we received from one of our North American customers.

    This development team decided to replace JSF by UltraLightClient halfway through the project. Despite this major change, the project deadline was not extended. Nevertheless, the team managed to deliver in time. Here’s what the Project Lead for Web and User Interface Development had to say on UltraLightClient:

    1. JUnit testing With JSF, unit testing of the interface required much contortion and difficulty in order to make sure the html interface was rendering the correct html. With ULC and Jemmy, the process is as easy as naming the widget and testing its behavior or content. This made for not only easier testing, but far more and far better test cases as the developers had more times and better ease of implementation.
    2. Extremely easy communication with the model. Eliminating the deployment descriptors of JSF, we could interact with the model by actually accessing attributes and calling methods directly on the actual objects. This eliminated the continual transformation between objects and beans, etc that JSF requires. I realize a lot of this can be facilitated with tools, but it seemed even better just to eliminate this needless transformation. Also, the performance was far better with this direct access to the model.
    3. Deploying locally. This is the holy grail of ULC. The fact that I can hit in Eclipse and see exactly what I am working with, or even better, put a break point in the test case and play with the specific part of the interface from there without having to deploy the application! WOW! This reduces developer time by hours per day.
    4. Rich functionality of ULC widgets. This may seem like just a perk to the interface but it is a development issue as well. The fact that the widgets are so feature rich allows the developer to spend less time trying to simulate rich features in DHTML or JavaScript and more time actually realizing the requirements of the application.

    I believe these 4 points are the most important benefits we realized in developing in ULC. (…) We built a full fledged loan renewal system interface in 5 months (4-6 developers). This would have been impossible without the development ease of ULC.

    Other corporate customers say similar things

    Please feel free to contact the ULC sales team and ask for further references.

    Further links:
    Pricing
    Case Studies

    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

    Canoo Code Camp: September 08 Edition

    September 12th, 2008

    Some photos from the Canoo Code Camp, currently taking place somewhere in the Swiss Alps, are appearing in our Flickr stream:

    08_09_Canoo_Codecamp 032

    08_09_Canoo_Codecamp 028

    The Code Camp is an internal event where Canoo developers take some time to evaluate new technologies and develop project ideas. For example, at last year’s camp, we had a closer look at Java FX and developed this sample application.

    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

    Canoo.net Talk at BlogCamp Switzerland

    September 9th, 2008

    Stephan Gillmeier and I attended the recent BlogCamp in Zürich, Switzerland.

    Stephan presents the Canoo.net blog

    Stephan Gillmeier presented an excellent talk on Canoo’s German language blog “Fragen Sie Dr. Bopp” (in English “Ask Dr. Bopp”):

    www.canoo.net/blog

    This is where Canoo’s chief linguist Dr. Stephan Bopp publishes some of the questions we receive at www.canoo.net.

    As a special highlight, Stephan Gillmeier revealed one of his plans for Canoo.net:

    Look up German words from your iPhone

    An iPhone application to look up words on Canoo.net.

    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

    Canoo CEO to present course on RIA and AJAX at ETH Zürich

    September 3rd, 2008

    Hans-Dirk Walter, CEO at Canoo EngineeringCanoo’s CEO Hans-Dirk Walter is presenting a one day course on Rich Internet Applications and AJAX on 12th September 2008.

    The RIA course is part of a three day training “Web-basierte Informationssysteme” from 10th to 12th September 2008 and will be held in German at the ETH in Zürich. Participants may choose to attend only one day or the entire course.

    Praktisch alle Menschen haben Zugang zum “Web”, sei es privat, dienstlich oder zunehmend auch mobil. Das Web ist damit praktisch jederzeit für jedermann verfügbar. Der große Erfolg des Webs liegt darin begründet, dass das Web die Kosten für das Abrufen und Bereitsstellen von Information stark reduziert hat. Dieser dreitägige Kurs stellt die grundlegenden Technologien des Web und der Entwicklung von Web-basierten Anwendungen vor. Am ersten Tag werden Web Services und dienstorientierte Softwarearchitekturen (SOA) vorgestellt, die die Grundlage für verteilte Informationssysteme bieten. Am zweiten Tag wird XML als eine der grundlegenden Technologie zur Repräsentation, Speicherung, Austausch und Verarbeitung von Information vorgestellt. Am dritten Tag werden Rich Internet Applications und die Programmierung von modernen graphischen Benutzerschnittstellen behandelt.

    Here is a summary of the RIA topics that will be presented (in German):

    Rich Internet Applikationen (RIA) sind die nächste Generation der Webtechnologie. Sie verbessern die Benutzerschnittstellen und erweitern den Anwendungsbereich von Webapplikationen entscheidend. Ihr wesentlicher Beitrag: sie verbinden die Vorteile server-basierter Web-Technologie mit Interaktionsmöglichkeiten für den Benutzer, die man sonst nur von lokal installierten Desktop-Applikationen kennt.

    Durch das Schlagwort AJAX und Anwendungen wie Google Maps, Flickr oder e-Opinion, die mit dieser Technologie implementiert sind, wurden Rich Internet Applikationen über die technische Entwickler-Community hinaus bekannt.

    Häufig wird übersehen, dass AJAX nur eine (sehr einfache) Implementierungsalternative ist, um das übergeordnete Ziel ergonomischerer Benutzerschnittstellen zu realisieren. Dieser Kurs gibt einen Überblick über die Ziele, die man durch den Einsatz von RIA Technologie verfolgt, die Architektur und Entwurfsmuster für Rich Internet Applikationen sowie einen Überblick über Technologiealternativen, um solche modernen Systeme zu realisieren. Zusätzlich zu den Konzepten werden Demonstrationen und praktische Beispiele geliefert, um eine richtige Erfahrung mit diesen Technologien zu bekommen.

    Summary of the Course Details:

    When: Wednesday 10th September 2008 to Friday 12th September
    Where: ETH Zürich, IFW-Gebäude, Hörsaal A 36 , Haldeneggsteig 4
    Lecturers:
    Prof. Dr. G. Alonso, ETH Zürich
    Prof. Dr. D. Kossmann, ETH Zürich
    Dr. H.-D. Walter, Canoo AG
    Course name: Web-basierte Informationssysteme

    ETH Zürich Kompaktkurs zum Thema RIA und AJAX


    Register for this course
    at the ETH Zürich website.

    This course is part of an ETH Zürich course program for IT professionals called “Kompaktkurse für Informatiker”.

    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

    css.php