Rich Internet Applications (RIA) » AJAX

GWT UiBinder: Better Web App Separation of Concerns

alberto — Mon, 26 Apr 2010 09:44:10 +0000

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:



    Search application



    Search:
    
        Query:
        
        
    


    Results:
    
        Result 1
        Result 2
        Result 3

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


public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        Widget searchBox = createSearchBox("Query:", "Go!");
        Panel searchResults = createSearchResults();

        VerticalPanel mainContainer = new VerticalPanel();
        mainContainer.add(new Label("Search:"));
        mainContainer.add(searchBox);
        mainContainer.add(new Label("Results:"));
        mainContainer.add(searchResults);

        RootPanel.get().add(mainContainer);
    }

    private Widget createSearchBox(String inputLabel, String buttonLabel) {
        HorizontalPanel searchBox = new HorizontalPanel();
        searchBox.add(new Label(inputLabel));
        searchBox.add(new TextBox());
        searchBox.add(new Button(buttonLabel));
        return searchBox;
    }

    private Panel createSearchResults() {
        VerticalPanel searchResults = new VerticalPanel();
        for (int i = 1; i <= 3; i++) {
            searchResults.add(new Label("Result " + i));
        }
        return searchResults;
    }
}

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:



    Search GWT application




    Search:
    
        
        
            
            
            
        
        
    
                Query:
             
                
            
    Results:
    
        Result 1
        Result 2
        Result 3

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:


public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        SearchComponent searchComponent = new SearchComponent();
        RootPanel.get().add(searchComponent);
    }
}


public class SearchComponent extends Composite {
    interface Binder extends UiBinder {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
    }
}

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”:


public class SearchComponent extends Composite {
    interface Binder extends UiBinder {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
    }
}

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:


public class SearchComponent extends Composite {
    interface Binder extends UiBinder {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;
    @UiField
    UListElement results;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
        queryInput.getElement().setId("queryInput");
        for (int i = 1; i <= 3; i++) {
            results.appendChild(createResultsItem("Result " + i));
        }
    }

    private Element createResultsItem(String value) {
        LIElement result = Document.get().createLIElement();
        result.setInnerHTML(value);
        return result;
    }
}

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:


public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        Panel searchResults = new FlowPanel();
        Widget searchBox = createSearchBox("Query:", "Go!", searchResults);

        FlowPanel mainContainer = new FlowPanel();
        mainContainer.add(new Label("Search:"));
        mainContainer.add(searchBox);
        mainContainer.add(new Label("Results:"));
        mainContainer.add(searchResults);

        RootPanel.get().add(mainContainer);
    }

    private Widget createSearchBox(String inputLabel, String buttonLabel,
                                   Panel searchResults) {
        HorizontalPanel searchBox = new HorizontalPanel();
        searchBox.add(new Label(inputLabel));
        searchBox.add(new TextBox());
        searchBox.add(new Button(buttonLabel,
                      createClickHandler(searchResults)));
        return searchBox;
    }

    private ClickHandler createClickHandler(final Panel searchResults) {
        return new ClickHandler() {
            public void onClick(ClickEvent event) {
                for (int i = 1; i <= 3; i++) {
                    searchResults.add(new Label("Result " + i));
                }
            }
        };
    }
}

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:


public class SearchComponent extends Composite {
    interface Binder extends UiBinder {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;
    @UiField
    Button searchButton;
    @UiField
    UListElement results;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
        queryInput.getElement().setId("queryInput");
    }

    @UiHandler("searchButton")
    void buttonClick(ClickEvent event) {
        for (int i = 1; i <= 3; i++) {
            results.appendChild(createResultsItem("Result " + i));
        }
    }

    private Element createResultsItem(String value) {
        LIElement result = Document.get().createLIElement();
        result.setInnerHTML(value);
        return result;
    }
}

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.

Conclusions

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

Felix Schrape — Mon, 25 Jan 2010 14:29:23 +0000

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

Mike — Thu, 25 Jun 2009 13:25:51 +0000

Session title: Agile and Secure; Can we do Both?
Speakers: Jason Li & Jerry Hoff, 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?

Mike — Wed, 24 Jun 2009 12:23:02 +0000

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…

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.
AJAX support inspired by RichFaces, IceFaces, DynamicFaces, ADF Faces. Enables AJAX elements to be specified decleratively or programmatically.
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.
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!!!
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.
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,
Behaviours enabled you to attach a behaviour to a component in a way which I didn’t quite understand.
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.
Exception Handler enables a single point of failure handling to be defined for a given app.
Validation is integrated with JSR303 Bean Validation
New Scopes have been defined: “conversation” (enables wizard-type functionality); “Flash” inspired by Ruby on Rails, which is used in Master-Detail situations; …
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

Mike — Tue, 23 Jun 2009 13:54:50 +0000

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!!!

J1 Session-Blog: Ajax vs. JavaFX Technology

Mike — Wed, 03 Jun 2009 07:50:54 +0000

First note that the speakers Ben Galbraith and Don Almaer are co-founders of ajaxian.com, which is clearly an AJAX-shop. They claim that Web technologies and Java went stagnent in the UI space. Ajax and JavaFX have the characteristics of a renaissance. They structure the talk in the form of a “discussion” or a series of arguments, where one supposedly pits the advantages of said technology against the other.

Argument #1: Java performs way faster than JavaScript; on the other hand JavaScript is getting faster all the time (V8 team at Google); plus apps like Google wave demonstrate that performance is good enough.
Argument #2: Responsiveness improved by worker-threads in a Java GUI. Yet using “web workers” we can overcome the limitation of JavaScript to a single thread. Demo of Pictastic proves the point. Having said that, web workers are still 10 times slower than Java; plus the API is extremely limited. In “web worker”, worker threads don’t share state, which is way safer than the totally flexible Java approach.
Argument #3: GC way more advanced in Java. On the other hand, incremental GC in Mozilla is improving all the time. A lousy fact of the JVN is having to determine how much memory the app requires (or how much is available) wherever the app is deployed.
Argument #4: Graphical capabilities of Java surpass what web apps can do. But performance of Bubblemark benchmark app shows that Google chrome achieves 100 frames per second. By comparison JavaFX achieves 24 FPS. With vector graphics Chrome is back down to 30 FPS. What the speakers don’t consider is that JavaFX is a very new and to-date under-optimised technology.
Argument #5: An Ajax 3D demo “metatunnel” is pretty impressive. Most browsers, apparently, are offering 3D extensions. It’s still at the experimental stage, however. JavaFX, on the other hand, has nothing to show in 3D.
Argument #6: Java is weak on fonts. The speakers claim that can’t use native fonts in Java (is this true? I seem to remember supplying Java with some additional fonts some years back.) Control over fonts in the Ajax world is even more limited, however.
Argument #7: JavaFX provides “amazing” video support. Counter argument: Flash plugin us ubiquitous and surpasses JavaFX in terms of maturity. Open Web Video offers sophisticated video functions.
Argument #8: Binding in JavaFX is compact and elegant. Web toolkits are very clumsy by comparison. The speakers quickly mention Mixins, Animation and Effects. All of this is way easier in JavaFX…
Argument #9: Legitimate critisisms are raised about JavaFX syntax. Speakers suggest that JavaScript is actually easier and closer to Java than JavaFX Script. And, of course, JavaFX totally lacks widgets like table/tree. Web toolkits even provide some very cool layout management and tools for constructing GUIs.
Argument #10: Tooling superior in the Java world.
Argument #11: Deployment. Web wins here, obviously, except for significant browser incompatibilities. Applets, Mac etc. are lousy too, however.

Conclusion: A pretty damning result for JavaFX, which is for the most part justified (at least today.) What the speakers fail to do, however, is talk more fairly about the significant problems faced by AJAX developers on a daily basis.

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

admin — Wed, 03 Sep 2008 12:52:16 +0000

Canoo’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

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

Feature Article on Building RIA for Business Users

admin — Thu, 10 Jul 2008 13:25:54 +0000

it management has published an article by Canoo’s CEO, Hans-Dirk Walter on building Rich Internet Applications (RIA) for business applications (in German only).

The article provides a short introduction to RIA and some of the business benefits it offers such as automating global business process, consolidating applications or enabling Software as a Service (SaaS). The article discusses the various evaluation criteria that are relevant when selecting a technology.

An welche Benutzer richtet sich die Anwendung – soll sie innerhalb eines Unternehmens oder als B2B-Lösung mit Geschäftspartnern eingesetzt werden oder richtet sich die Anwendung an beliebige Benutzer im Internet?

Wie arbeiten die Benutzer mit der Anwendung? Wird sie gelegentlich aufge-
rufen oder wird sie von Experten täglich und sehr intensiv zur Erledigung
von wichtigen Aufgaben verwendet?

Handelt es sich bei der Anwendung um eine Geschäftsanwendung (z.B. ein CRM- oder ERP-System) oder um eine Anwendung mit Unterhaltungscharakter, in denen Animationen und Multimedia eine grosse Rolle spielen?

A .pdf is available online in the press section of the Canoo website.

Grails Sample Application: ria-map.net

admin — Wed, 18 Jun 2008 08:00:26 +0000

Canoo has released a new sample application at ria-map.net. The application shows typical Web 2.0 interface elements such as tagging or Flickr-like editing fields.

I asked the developer, Jonas Zuberbühler, the following questions on the new Canoo sample application.

SW> What is riamap?

riamap is a Web 2.0 community site that maps the world of Rich Internet Applications. Unlike mere information aggregators on the topic, it builds on user contributions to assemble not only a list of current RIA technologies, but also how they relate to each other.

Users can explore what technologies are available, what they have in common, how they differentiate, what competitors they have and how they complement each other. These relations make up a graph that any user can extend by adding new connections or voting how strong any such connection based on his or her own judgment.

SW> What technologies did you use to build it?

We used Grails for the web application framework and Groovy as it is the perfect partner for implementing server-side logic.
In addition, we used Prototype, Scriptaculous and LivePipe to integrate AJAX features and to improve the user interface.

SW> Why did you select Grails? Why not adapt an existing PHP- or Java-based content management system?

Canoo has a strong footing in Java and Grails is the perfect choice for developing Web 2.0 applications on the Java platform. We can build on our solid understanding of this ecosystem and use all the existing tools for development, deployment and operations. On top of this, Grails provides us with the concise, expressive and interactive development style that modern applications require.

Further screenshots:

To get a login for riamap, sign up here to join riamap. Try out the various Web 2.0 interface features. If you feel like adding information on a RIA technology, enter the details here or edit an existing entry.

JavaPolis 2007 – Desktop RIA and Mobile Apps rock the Scene

Christian — Thu, 13 Dec 2007 11:56:46 +0000

This morning, I attended the second keynote at JavaPolis 2007 in Antwerp. Although it was not the “big” keynote (that one was held by James Gosling the day before), it was definitely the more interesting one to me. This is why:

First, the Java community was hit by two extremely cool Flex demonstrations: at the beginning, Bruce Eckel and his co-speakers showed a Flex-based data manager framework that allows transparent and smooth synchronization of client-side and server-side business data, even between multiple clients and with clustered server nodes. Data changed on one client gets synchronized to the server (for example: to all cluster nodes) and then back to all connected clients. Not only does it allow the application to determine the “transaction commit point”, but it also provides support for conflict handling (again, the conflict reconciliation handling can be fully controlled by the application). Whenever a client goes offline, data changes are locally tracked and synched back to the server as soon as the connection is re-established. Failed cluster nodes get updated as soon as they rejoin the cluster. In addition, the data manager can also be used with Ajax applications. Although the demo application looked quite “ugly” (for a Flex demo …), the technical brilliance led to spontaneous applause …

The second rocking Flex demo was Parleys.com beta: well-know for slick and smooth video and slide show streaming, Parleys.com is about to get a face-up. Well it’s more like a revolution. While it was based on Ajax in version 1.0, the new technology chosen is Flex. Of course, the visual effects are extremely slick and appealing. But what is way more interesting to me from a RIA point of view is the integration of the online, browser-based version with an offline Parleys.com client application based on AIR. When both clients are running, the browser-based one automatically gets enhanced by features available in the offline client – such as offline video availability – by smoothly adding new buttons and actions to the online client. That really rocks from a user experience and integration point of view! The new Parleys.com version is about to be released in Q1/2008.

But there is a fight-back from the Java side: also worth mentioning here is the Java approach of browser-based RIA that was demonstrated in the IRIS sample application. First showed to the public at the last JavaOne, this application does not stand behind the Flex-based ones in any way when it comes to visual effects. The IRIS approach smoothly integrates Java applets with an ajaxified Web application. It was almost impossible to say what feature was powered by the applet and what was done using Ajax – and what was done by tightly combining these two technologies even for a single user interaction. The revival of the applets!

To me, all these demos really show to me that RIA is still steadily increasing in importance. There is way more than just adding a few fancy Ajax effects to static web page – and the big vendors and technology owners are pushing the car forward. And the desktop is really moving back into the RIA world – it is no longer all about pure (and old) browser technologies, but about JNLP, applets, AIR & Co.

But there was also another unexpected “flasher” in that keynote: JavaME. JavaME? Isn’t it dead? No, it’s not! Sun showed up with the new Netbeans Mobility 6.0 that extremely simplifies the development of JavaME-based games. But not only games, also business applications are finally showing up in the JavaME space (and are supported in a graphical way by the mobility tool). Using the SVG-rendering facility available in the MSA (Mobile Service Architecture), these UIs now can really look awesome (forget these old and ugly “text-based” mobile UIs …). And by adding JavaFX Mobile to the scene, Sun is pushing the Java mobile stack even further. As with Google’s Android, Sun aims to provide a complete software stack based on a Linux kernel that offers Java-based APIs to all phone capabilities which are then used by all the device vendors, third party RIA software service providers and the community to develop new-class mobile RIA applications. It will be very interesting to see whether Sun or Google (or both?) will make the deal with their approach. In the end, I think the device vendors are going to decide this battle: every cool software platform is only worth noting if there are a big bunch of devices available that ship the software by default.

A few resources:

All this mobile stuff now really seems to shake a leg. Very exciting!