• Home
  • Events
  • About
  • GWT UiBinder: Better Web App Separation of Concerns

    April 26th, 2010

    One of the newest features introduced in Google Web Toolkit 2.0 is the “UiBinder“. This new way of building views allows the developer to use a declarative approach when doing the layout of a GWT application.

    In case you have not heard about it, GWT is a set of tools that enables Java developers to develop “rich web applications” in the Java language. The term “rich web application” implies two things:

    • Desktop-like interaction, where a user action has immediate feedback (e.g.: input validation, search box terms suggestions, results highlighting, etc) without requiring a server round-trip (executing an HTTP request with the result of reloading the page being browsed). In the world of web applications, this is typically accomplished using Ajax (what is also what GWT does).
    • An application running within a browser, but using native browser technologies (HTML, CSS and JavaScript). If we were talking about applications held in browser plug-ins and running out-of-process within their own virtual machines or by mean of run-times, I would prefer to use the more general term “rich internet applications”. These are launched from a web browser but behave as black boxes for other user agents (e.g.: web crawlers).

    GWT allows us is write Ajax-based “rich web applications” using the Java language instead of the traditional JavaScript. GWT takes your Java code and compiles into JavaScript, HTML, and CSS. So while you write the program in Java, it is translated into a traditional web application.

    Building user interfaces in GWT

    The most common approach to building desktop application interfaces is using visual components called “widgets”. For developers with Swing experience, GWT seems a marvellous step forward because it allows you to leverage most of your knowledge with far less effort than the alternatives. I say seems because this can also be of disadvantage, as I’ll show with an example.
    If we had to create a web interface for a simple web search application, the most common way of doing the interface would be an HTML form for submitting the query and an HTML list to show the results:

    In the case of GWT, a Swing developer might write widget and layout code like this:

    This approach is a valid one and, with some CSS styling, produces a neat interface, but it introduces a too complicated DOM structure that does not scale well for bigger applications:

    Compare the handcrafted HTML tags with the DOM produced using GWT widgets, and the first one is simpler. One of the reasons of the extra verbosity of the GWT one is the use of “HorizontalPanel” to layout the search box horizontally. This is a panel based in tables and it introduces a “too verbose” HTML table for the layout. In the case of a horizontal layout, we can also use a FlowPanel, altogether with some CSS styles, to avoid the search box components stacking vertically (which is the default layout for the HTML “div” elements that a “FlowPanel” produces). The problem is that this approach mixes widgets for layout with CSS for layout (not for styling) what stops being a pure widget approach.
    The next thing to notice in the DOM produced by GWT is the excessive presence of GWT CSS classes (e.g.: “gwt-Label”, “gwt-TextBox”). While they are most times useful when it comes to style the widgets, they are many times not used or they do not fit always our CSS selectors strategy.
    Lastly, there is a lack of HTML semantics in the DOM produced by GWT. Almost every element is a “div”. From the point of view of web standards, it is much more convenient to use an HTML list for the results as it is to use a collection of “div” elements. Producing HTML labels associated with form fields (search box label) is also a usability and accessibility improvement. Using tables for layout should be avoided.
    For a real-world application that use input fields, trees, tables, “tab panels” or splitters, etc… all in the same screen, it is a good practice to get rid of the intermediate superfluous DOM elements. It reduces drastically the amount of “glue” elements, making the DOM much more compact and faster to modify. We should avoid “glue” and automatic generated code, because it needs to be compiled, loaded, executed and maintained. In the case of an overly verbose DOM structure, CSS issues may appear because of the complex structure interactions. Fixing them is akin to fixing bugs in generated code: very difficult!

    Mixing HTML and Widgets

    So how can we mix widgets and html properly? Before GWT version 2.0, the most common way was to use “RootPanel.get(‘someId’)” to access an HTML element in the application host page, and then create an object there to attach the widgets to (ie. a “RootPanel”). If we need to embed only a few widgets in the host page, this technique suffices. But doing this in a real application with a large number of widgets becomes complex and slow.
    UiBinder scales better because it does not inject widgets into the HTML of the host page. Instead, you declare your layout in a stand-alone HTML file that can be composed with other components as many times as necessary to build more complex interfaces. Composition entails componentization, allowing the developer to create subparts of the user interface (UI components) that can be packaged, re-used and tested in isolation.
    But let us see how with an example:

    Our example has been split into three files: the first one is the GWT entry point, that now only instantiates and inserts our new UI component at the interface top level. The second is an XML file representing the view and is required by UiBinder to act as a mark-up template. The third is the Java class implementing the component logic (that as of now is almost non-existent) and invoking UiBinder.
    If you run this code so far, you will notice that now the appearance is exactly the same as in the handcrafted HTML and that there is not yet real integration between the view of the component (mark-up template) and the logic of the component (Java class). Let us fix this by substituting the HTML input field with a GWT “TextBox”:

    Notice the changes in the template where the HTML input field has been substituted by “” and also the little change in the Java class that now has a field of type “TextBox” annotated with “UiField”. When the Java class is instantiated, the UiBinder creates and injects the “TextBox” using the matching field name and “ui:field” attribute. The result is almost the same DOM structure with only some extra attribute values generated by GWT. Note that we also eliminated the “id” HTML attribute. This last change is because of a current limitation in UiBinder which does not allow defining both attributes in the same element. This issue can be solved setting the id attribute in the constructor after the UiBinder has been invoked.
    As next step, let us now integrate the results list by writing out some simple HTML list elements:

    The changes in the UI Binder template is almost the same as the previous one with a subtle difference: in the previous step, we integrated a GWT widget (“TextBox”) replacing the HTML input element. In this second case, we performed a to “bind” the “ul” HTML element from the view because there is no GWT list widget that matches a simple HTML list. Instead of using the API of a GWT widget, we are using the GWT DOM API to directly modify it.

    Adding behaviour

    Let us now go back to the first GWT approach and modify it to create the results when clicking the button. This is what your pre-UiBinder code might look like:

    Here we introduced a “ClickHandler” that modifies the results container with some fake ones when the search button is clicked.
    Doing the same with the UiBinder approach results on the following code:

    We introduced a “Button” GWT widget in the mark-up template together with its corresponding field in the Java class. We also moved the code creating the results to its own method annotated with “UiHandler” (take into account that the signature must be compatible with a “ClickHandler”). Finally, we removed the “form” element from the mark-up (which is not required at all in an Ajax application).
    One of the core design principles in the development world is the benefits of separating logic and presentation. What would happen if now we wanted to change the place where the results appear in relation to the search box? Or, if we wanted to get rid of the “Results:” label because it is not necessary? In the first GWT approach taken, the way in which the widgets are created and nested is reflected in the Java code together with our logic, making necessary changes to this code. Also “static” presentational elements, like the “Results:” label, are embedded in the code where. Applying the separation of concerns principle tells us that they do not belong there. Making a change to either presentation or logic necessarily requires changing both presentation and logic. In the “UiBinder” approach, because of its inherent separation of concerns, these changes would happen only in the mark-up template or in the domain logic, not in both.


    • When building a web application, no matter which framework you use, never forget that you are still using HTML, CSS and JavaScript. The simpler the DOM produced, the faster the application will perform and the less CSS issues you will find.
    • Web applications have web pages! Always try to use the most semantic HTML structure you can. It improves SEO, usability and accessibility and usually produces compact DOM structures.
    • Even when you program in your favourite language and do everything in code by mean of widgets, do not forget the advantages of principles like presentation and logic separation. Using UiBinder in GWT produces twice the number of files but each is simpler, cleaner, easy to manage, and easier to maintain.
    • With presentation separation, you can let your design team produce a HTML prototype of the different parts of your application that can be easily reused afterwards or even in parallel. Two teams being able to work in parallel reduces the project time span and using prototypes reduces the project risks.
    • Because different tasks require different skills, let the developers code and the designers deal with HTML and CSS. They all will be much happier and the application will be and look much better.

    RIA Forum on GUI Technology

    January 25th, 2010


    We are happy to announce the second RIA forum which will take place in Darmstadt (close to Frankfurt), 23rd of April 2010! This time, with Canoo Engineering AG as premium sponsor, four well known speakers will talk about the advantages and disadvantages of four different ways to create effective user interfaces (especially in business contexts).

    Instead of giving details here I recommend to visit the forum page directly: http://www.riaforum.com (in German). Please be aware that we can only provide entrance to a limited audience, so if you want to join, make sure you sign up quickly.

    Jazoon '09: Addressing security in the agile process

    June 25th, 2009


    Session title: Agile and Secure; Can we do Both?
    Speakers: Jason Li & Jerry Hoff, Aspect Security

    Jerry Hoff and Jason Li of Aspect Security

     Goal: To try to get developers to think about security early on in the development process.

    Jason begins with a brief description of a common security flaw (in AJAX apps at least) XSS, which typically involves replacing regular text with a malicious piece of JavaScript. Example attack: The JS steals the end-user’s cookie by querying the DOM. A cross-site request forgery might subsequently be mounted by using the stolen cookie from within a new application context such as mail in order to delete all the users mail.

    Another example – SQL injection – is when part of a SQL statement is replaced with a semi-colon followed by another statement e.g. DROP TABLE… which is obviously bad news.

    With that whirlwind tour of web security… how to fix the process which results in such errors?

    Speakers refer to the waterfall and explain how in each of the chunky phases activities include (or should include) security; security requirements, security design etc…

    Speakers then argue that embellishing the highly iterative agile process in the same way as was done for waterfall is not practical. Blogger agrees… the granularity of the activities is too fine to permit the kinds of security analyses which are required. So what’s the solution?

    They recommend…

    Leveraging user stories

    Prerequisite step: Ensure that all developers have received adequate security training

    Another prerequisite step: Get management to fund this (gets a laugh!)
    Alternatively: The OWASP Open Web Application Security Project is an organization providing resources which provides heaps of information on attacks points and solutions for these.

    Leverage unit testing… and include security tests in the unit tests. This is obviously particularly effective in a continuous integration environment.

    To speed up this process, use common security components such as those at Open Enterprise Security. Organizationally, this needs to be communicated across the development team(s).

    Leverage and consolidate sprints… and ensure that all security stories are included in each sprint. For dealing with security stories which don’t fit into any particular sprint, run sprints that are focussed solely on security.

    Great line (paraphrased): Web apps are a kind of “perfect storm” comprising a complex mixture of technologies, which results both in a large attack surface area as well as numerous subtle edge cases which make us more vulnerable.

    Couldn’t agree more!!!

    I found this talk excellent both stylistically and, more importantly, in terms of content. There are still voices out there which claim that agile in some way incompatible with quality. Talks like this should go some way to quell those remaining voices. Although the pair used AJAX’s inherent security vulnerabilities to highlight the necessity for a systematic approach to security in agile environments, much of what they recommend applies to any agile environment, whether it is creating AJAX applications or not.

    What’s new in JSF 2.0?

    June 24th, 2009

    Session title: A complete Tour of JSF 2.0
    Speakers: Ed Burns – Sun Microsystems, Inc
    Martin Marinschek – IRIAN Solutions

    My interest in this talk is simple to explain: I used JSF in a really cool project last year, and found it cable but wanting in a number of respects. Lets see if the problems have been addressed…

    The speakers begin with quite a few words about how the JSR was the result of a community effort. Then note that JSF 2.0 doubles the scope and integrates Facelets.


    And the new features are…

    1. Composite components. To a large extent the philosophy is the same as for rails with pay as you go complexity. Goal was to enable true abstractions. Makes heavy use of naming conventions to reduce verbosity. Composite components builds on top of resources and facelets. Nice to know: Mojarra supports Groovy.
    2. AJAX support inspired by RichFaces, IceFaces, DynamicFaces, ADF Faces. Enables AJAX elements to be specified decleratively or programmatically.
    3. Partial state saving. Biggest problem for performance to-date was the size of the state. Everything was a state and every request was a post. Pre-view state size is now 25% less than prior to 2.0.
    4. View parameters. Inspired by Page Parameters from Jboss Seam. Provides a way to map requests parameters to special components within the view. Reduces the need to redeclare all the params across all the pages in the app. I had this problem in the aforementioned app and am glad to hear this issue has been addressed!!!
    5. System Events. Inspired by Dtrace, influenced by JSFTemplating. This is a publish/subscribe event bus for the JSF app. A suite of events is provided. The list may be extended.
    6. Resources mechanism is now standardised. Separate Filter or Servlet is now no longer necessary. Resources are now logically related to components. Full “library” support (whatever that means), I18N, versioning,
    7. Behaviours enabled you to attach a behaviour to a component in a way which I didn’t quite understand.
    8. Navigation enables pages to be bookmarked. Uses the View Parameters feature to ensure params are validated before rendering the page. Implicit Navigation enables pages to be bookmarked.
    9. Exception Handler enables a single point of failure handling to be defined for a given app.
    10. Validation is integrated with JSR303 Bean Validation
    11. New Scopes have been defined: “conversation” (enables wizard-type functionality); “Flash” inspired by Ruby on Rails, which is used in Master-Detail situations; …
    12. FacesConcext used during startup/shutdown eases the business of keeping things tidy.

    I may have missed one or two points during this rather information-intense session. Nevertheless interesting stuff. Big take-home: JSF2.0 appears far easier to use than its predecessor. It’s also much bigger.

    Conclusion: Valuable information, competently presented.

    Having been asked 2-3 times at Jazoon about my JSF experience. I now have the impression that interest in JSF is pretty high – and growing. I’d have to go back and look at my notes about the project to see what we could have done better using these new features.

    Jazoon '09: RIA and Security

    June 23rd, 2009

    Session title: RIA Security: Broken by Design
    From: Joonas Lehtinen, CEO IT Mill

    IT Mill is the creator of Vaadin: A 100% Java tool for RIA.

    Joonas outlines a spectrum of complexity from Basic site to 3D games examples:
    Web Sites (Wikipedia), AJAX Sugar (Facebook), Full RIA

    He divides „Full RIA“ divide into client side vs. Server driven. Gives a crash course in GWT.

    Vaadin: Apparently 100% Java and server driven, which sounds an awful lot like ULC at this stage… But here’s a difference: It builds on GWT and relies on JavaScript on the client-side.

    He goes on to present a bunch of development rules:

    Rule #1: Don’t trust the browser
    Rule #2: Complexity is a hiding place for bugs
    Rule #3: Large surface give more opportunities for attack. This surface has increased with Web 2.0.



    Difference between GWT and Vaadin architectures is that GWT relies on the client invoking a server-side Web Service API, whereas Vaadin renders the client’s view on the server.

    Erm… he then offers the cures for the problems (Rules above)… which I miss because the explanation is compressed into around 5s.

    I’m starting to dislike this presentation at this point. Because here comes another artificial security issue scenario… which guess which product solves. And I thought product placement in Hollywood movies was irritating.

    The issues he raises are legitimate, but the lack of objectivity is obscuring the message. And as I write the presenter is debugging JavaScript which depends on analysing the DOM on the client side – I’m not sure if he’s now analysing the problem or trying to fix it!?

    I am formally declaring myself lost at this stage. At least I hope the other attendees are getting something out of this presentation, which has lost focus IMO.

    He continues with a discussion about attacking at the transport level, inserting new data on the fly. But come on: A secure transaction in this technical setting will operate under HTTPS, which in most instances will deal with this kind of attack. Unless, of course, that’s something else I missed.

    I think I need a coffee!!!