• Home
  • Events
  • About
  • Desktop Matters presentation

    March 26th, 2007

    Here is the presentation Etienne Studer held at Desktop Matters:

    PDF file (213 KB)

    This is what Paul Krill of Javaworld had to say:

    Another technology discussed, Canoo UltraLightClient, leverages Swing
    and a Web architecture. Application logic resides on the server, rather
    than the client. A component-oriented programming model is leveraged.
    The UI is rendered in Swing rather than in HTML.

    “You get a much richer user experience,” this way, said Etienne Studer,
    a developer at Navis who worked on development of the framework when he
    worked at Canoo. Now, he uses UltraLightClient.

    “It’s like a better AJAX (Asynchronous JavaScript and XML) then,” said
    one audience member, responding to Studer’s presentation.

    Studer cited one application of UltraLightClientClient in which it is
    being used in a marine terminal operations system by shipping companies.
    Users have access to the same UI.

    For other upcoming events, see the Canoo website.

    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

    Adding "search as you type" to your Web Application

    March 20th, 2007

    When trying to look up data in a database, a very helpful feature is “search as you type” functionality: you enter some characters and get the matching hits immediately before submitting your query. One popular AJAX example for this is GoogleSuggest

    I decided to add a similar feature to CanooNet, our popular German dictionary and grammar. And here are the implementation steps, using the AutoCompleter function of the script.aculo.us AJAX library:

    1. Follow the first three steps in the usage guide to integrate script.aculo.us in your web page.
    2. Refer to the AutoCompleter documentation to add the AutoCompleter to the web form.

      The first <td> displays the indicator icon while the search is running. The second <td> defines the input field and attaches the AutoCompleter to this field. The autocomplete=”off”- Input-Field-Option switches off the autocomplete of your browser – this would confuse while entering the characters.

    3. At the end of your form you can configure the AutoCompleter behaviour:

      The meaning of the parameters is:

      1. Name of the input field (‘input’)
      2. div-id of your <td>
      3. URL for the lookup. In our example a special Java servlet named AjaxController is called. This servlet returns the matches in a format that can be parsed by the AutoCompleter. The servlet is described below.
      4. Additional parameters:
        1. frequency indicated the time delay after a keystroke before triggering the URL
        2. minChars defines the amount of characters that have to be entered into the input field before triggering the URL
        3. indicator-id of the “wait while searching” icon
        4. Additional URL parameters can be passed using ‘parameters’. In our case we need a language parameter.
        5. afterUpdateElement: in our example a getSelection-Function is called to set the correct selected value into the input field.
    4. The Java servlet mentioned above implements a simple method returning the data that has to be displayed by the AutoCompleter:

      The data returned by the servlet looks like this:

      The AutoCompleter is able to differentiate between the information to be displayed in the drop down (e.g. “Gang (Noun)”) and the information to be passed as form parameter after selecting an entry (e.g. “gang”). The latter one is the input field value sent by the browser when the user hits the search button. The informal part of the display string is separated using .

      This is everything you have to do in order to establish a “search as you type” in your web form. While this is the “easy” part, improving the search performance is much more sophisticated: in CanooNet we have to match more than 250.000 word form entries using wildcards in order to get the information to be displayed by the AutoCompleter.

    And this is the result:

    CanooNet AJAX AutoCompleter

    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

    Bruce Eckel on using Java for RIA

    March 16th, 2007

    I stumbled across this posting at Indicthreads.com, discussing a recent article by Bruce Eckel:

    Bruce Eckel looks at “How And Why AJAX, Not Java, Became the Favored Technology for RIAs”. He begins with what’s wrong with Java and the web at large. He then looks at the RIA space, the alternatives, the challenges and why Java hasn’t managed to capture the market for client-side RIAs.

    He says “In fact, why do we like Ajax? It’s clearly not because JavaScript is so easy to work with—JavaScript cross-platform problems are the reason people have avoided it in the past. Ajax is popular because we know that the necessary software for the client side is already installed. Someone had to figure out how to deal with the cross-platform issues for JavaScript first, but if JRE installation was trivial, everyone might have just created Java applets. But they didn’t, applets are not ubiquitous, and everyone got excited about Ajax instead. So Ajax became the favored technology for RIAs.”

    “It’s not impossible to build GUI applications with Java, but it’s been 10 years and there are still installation hiccups with applets, Java WebStart, and regular applications. After 10 years, people don’t trust it anymore.”

    He then looks at how Flash and Flex could be possible solutions for creating powerful cross-platform UIs. Read the entire article on JDJ.

    For a contrary opinion have a look at why Marc Domenig feels that despite the hype around Ajax, Java Swing can be a much better option.

    As Indicthreads points out, Canoo has taken a different stance on this, shown by its continued investment into its thin Swing library. And reflected by various happy customers. See also Canoo’s list of advantages compared to Swing and Java Web Start.

    The JDJ article includes some valid criticism of Java. Clunky, boring and grey user interfaces is, in my humble opinion, one of them.

    Marc Domenig points out in a Javalobby article on AJAX and RIA, that there are many different evaluation criteria to consider on a per-project basis. Currently there is no one technology that fits all. This jungle of RIA possibilities has led Canoo to offer consulting services for customers that are grappling with this question.

    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 at Desktop Matters

    March 13th, 2007

    Etienne Studer held a presentation on UltraLightClient at the recent Desktop Matters conference in San Jose, California.

    Ben Galbraith wrote:

    Etienne Studer representing Canoo talked a lot about their UltraLightClient solution which is primarily about a way to distribute very small but fully rich Swing clients because a large amount of the processing occurs on the server. So, great way to have very small Java Web Start or Applets — and a great way to have distribution problems handled automatically.

    And in Etienne’s own words:

    In the ULC talk, I tried to highlight how effective it is to develop client-server applications using a pure server-side Swing-like programming model in combination with a Swing UI on the client-side and how ULC takes care of the distributed programming aspects transparently.

    Other Upcoming Talks:

    • Canoo’s CTO, Bruno Schaeffer is presenting at the AJAXWorld Conference in New York on 19th March 2007.
    • Etienne and Bruno will be speaking at SDWest on 23rd March 2007.
    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

    Building a Regular Website with the Google Web Toolkit

    March 13th, 2007

    The Idea

    Many nice and home-grown websites contain a navigation bar. But without a special design tool a navigation bar is not easy to build because it typically involves JavaScript programming. My idea was to build a simple and convenient tool such that a non-technical person with basic knowledge about static HTML can easily include a corresponding navigation bar in its pages.

    The person configures the navigation bar by composing or adjusting a rather simple XML file. The HTML writer should not have to deal with server-side page scripting or anything a like. For the website to work, it should be sufficient to deploy the XML and a bunch of static HTML files along with some ready-made magic. Trying out the site should be as easy as double-clicking the main HTML file in the local file system.

    I like Java and I did not want get my hands dirty with JavaScript and browser compatiblity issues. So how could I get the job done? Since I also like experimenting, I decided to give the GWT (the Google Web Toolkit) a go for the project.

    When reading the GWT’s documentation, its seemed like the perfect choice for me: I program my navigation bar entirely in Java and in the end, it is all converted to a highly optimized and pure client-side JavaScript / HTML mash. Wow!

    In the following, you can read about my related experience with the GWT and the many unexpected hurdles a had to take in order to reach my goal.

    Here is a brief summary about the problems I encountered and my general impression, after playing with the GWT:

    • The GWT misses (at least) some basic widgets, you may expect in an Ajax (library).
    • (At least some) of the existing widgets are difficult to extend.
    • The asynchronous programming model of the GWT (and Ajax in general) leads to problems,
      when creating higher level API. (You are forced to give it an asynchronous design, too.)
    • The GWT does not well support dynamic locale changes (details will follow in an upcoming blog entry).

    Although I was really enthusiastic about the GWT when I started, I have to admit that I got disappointed here and there.
    An upside is the GWT’s basic infrastructure (i.e. the compiler and the debugger), which seems very mature and stable.
    It’s really just the library that should be improved…

    Getting in Touch with the GWT

    If you are a reasonably experienced Java programmer, then getting started with the GWT is easy, and the quick results are motivating. So, after trying out some basic stuff, I wanted to make shure that the GWT API indeed allows me to realize my little project.

    The Navigation Bar Hassle

    The GWT library contains a widget, which is close to the kind of navigation bar I had in mind: the class com.google.gwt.user.client.ui.TabPanel. Unfortunately, it allows for creating horzitontal navigation bars only.

    When looking at the GWT kitchen sink example, it seems like there is a vertical navigation bar included – but that impression is misleading. The vertical navigation bar in the kitchen sink does not use a ready-made GWT widget. Instead, it is a custom built thing made out of a bunch of hyperlink objects (of type com.google.gwt.user.client.ui.Hyperlink)

    I wondered why Google did not add a built-in vertical tab panel and so I began to read the source code of the
    TabPanel and the affiliated TabBar class. I could not find any good reason why this widget should not be vertical and so, I tried to subclass TabPanel in order to get a vertical version of it. Sadly, my attempt quickly came to a halt, because the TabPanel had not at all been created with extensibilty in mind. The first few lines of code of GWT’s TabPanel reads as follows:

    The TabPanel is a composite widget, which consists of simpler widgets, namely a vertical panel, a tab bar and a deck panel. However, given the code from above, none of these contained widgets can be exchanged by subclassing, and therefore, it is practically impossible to get a vertical tab panel by by subclassing TabPanel.

    I felt disappointed: If the set of built-in widgets is small, then at least I expect a good degree of extensibilty of the corresponding framework.

    So how did I get my vertical tab pane then? By copy and patch! I copied the entire TabPanel code and turned it into my so-called FlexibleTabPanel class.

    Its first lines read as follows:

    The constructor of FlexibleTabPanel obtains a boolean, which decides, if the resulting tab pane is vertical or horizontal. The methods createOuterPanel() and createTabBar() may be overriden. Depending on the boolean flag, they create widgets for either the horizontal or the vertical case.

    As you might guess, I also had to copy and patch the class com.google.gwt.user.client.ui.TabBar. I even had to subclass (the standard GWT classes) HorizontalPanel and VerticalPanel: Both classes have certain methods in common but the GWT does not factor them out in a common superclass or super interface. However, the original TabPanel class counts on these methods with respect to HorizontalPanel. Since I wanted to use the corresponding code in FlexibleTabPanel for both the HorizontalPanel and VerticalPanel, I was forced to do the following:

    1. I created an interface, which contains the missing super class methods and it looks
      as follows:

      (IndexedPanel is an existing interface of the GWT, which just lacks the methods from above.)
    2. I subclassed HorizontalPanel and VerticalPanel in the following ways:

    The new classes FlexibleHorizontalPanel and FlexibleVerticalPanel offer the functionality needed in FlexibleTabPanel. So far I could not find any good reason, why the GWT does not share this functionality in a common super class of the vertical and horizontal panel already.

    Building the Builder

    XML and Properties Files for Configuration

    As I mentioned in the beginning, I wanted the navigation bar to be configurable via an XML file. Essentially the XML file should determine the structure of the bar and its contents. I wrote a little interpreter, which parses a related XML file and and turns it into a widget object hierarchy. This is a similar approach as in frameworks such as SwiXML and ULCXML, but for my purpose, the navigation builder, as I called it, acts on a much smaller scale.

    Here is a sample XML file that the navigation builder is able to digest:


    <?xml version="1.0" encoding="ISO-8859-1" ?>
    <navigation>
    <file id="home" xhref="home.html" mce_href="home.html" html="true"/>
    <file id="cv" xhref="cv.html" mce_href="cv.html" html="true"/>
    <file id="concerts" xhref="concerts.html" mce_href="concerts.html" html="true"/>
    <navigation id="gallery" orientation="vertical" default="true">
    <file id="image1" xhref="image1.html" mce_href="image1.html" html="true" default="true"/>
    <content id="image2">This image is not yet available.</content>
    </navigation>
    <file id="contact" xhref="contact.html" mce_href="contact.html" html="true"/>
    </navigation>

    Based on this file, the interpreter creates an outer navigation bar with five tabs. The first tab has the id home, and when selected, it displays the HTML file home.html. The next two entry work similarly. The fourth entry defines an inner navigation bar, which is vertical and contains two tabs itself: The first inner tab relates to the HTML file image1.html and the second one adds the text This image is not yet available. in place.

    As you can see, it’s usually HTML files, which determine, what’s displayed upon tab selection. But where do the display names of the tabs actually come from? For reasons I will explain later, I moved all of these names to Java properties files. E.g. the properties file navigation.properties for the XML file from above may look as follows:

    Every id defined in the XML file is referenced in the properties file and is associated with an English display text.

    Being Asynchronous is Contagious

    After that, it was time to build the navigation builder class itself. The GWT comes with a convenient
    DOM-based XML parser API and so, it was easy to write the interpreter code.
    Interestingly, the way to read a corresponding XML file with the GWT has a serious impact on the entire program structure.

    Reading files inside a Web page is real Ajax functionality, and the related GWT API must be used as follows:

    The code loads the file myfileName via a relative URL and upon success, the contents of the file is passed in as a string to the onCompletion() method.
    Since the method asyncGet() returns its result via a callback, it is called asynchronous. The navigation builder uses asyncGet() and therefore its API became asynchronous too:

    Asynchronous APIs considerably change the structure of depending programs and in the example above, an asynchronous low level API “infected” a higher level API.
    In the context of the GWT this effect is hard to prevent, because the native
    execution environment (Java Script) has no thread concept and no thread synchronization mechanisms.

    Results

    After putting it all together, I finally got a first version of the navigation bar. Follow this link to try out a corresponding example, which uses the XML file and the properties file from above.

    The file GWTSample1.zip contains all the related source code.

    Next week, I will talk about my adventures, when I tried to bring internationalization into the system. (Note that the code in the zip file contains the code for related feature already.)

    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