Posts Tagged ui

Mojarra Scales

The other day I was looking for a good UI charting package that plays nice with JSF and stumbled on Mojarra Scales, one of those cool little projects that reminds me why JSF seemed like such a good idea at the time. Basically it’s a wrapper for YUI charts that lets you bind them to a backing bean as the data source via JSF and configure many of the attributes declaratively through EL. For example, I created a chart showing min/max/average HTTP request time like this:

<sc:chart id="requestThroughputChart" type="line"
     value="#{charts.totalRequestThroughputChartData}"
     seriesDef="[{ displayName: 'Rate', yField: 'rate' }]"
     horizontalField="time" width="100%" />

For the backing bean it’s a little old-school in that it uses a simple string-property map:

public List<Map<String, String>> getTotalRequestThroughputChartData() {
     List<Map<String, String>> list = new ArrayList<Map<String, String>>();
     for (Summary s : result.getSummariesByTimeSeq()) {
          Map<String, String> map = new HashMap<String, String>();
          map.put("time", timeIndex(s));
          map.put("rate", s.getStatistic().getRate().toString());
          list.add(map);
     }<
     return list;
}

But hey, it works and is super easy to use – a good thing since their examples are sparing and the site has practically zero documentation. The result looks like this:

chart

It always feels like JSF could have gone farther if more things like this fit together: I think the haphazard piling of the API, differing implementations, renderkits, and component libraries by separate vendors always made things a little sticky, and to the uninitiated, often a configuration nightmare. There’s something to be said for frameworks that package it all up in a nice shiny box. But, projects like this still make me smile and appreciate being able to throw a good-looking chart on my site in minutes without touching Flash or JavaScript (or mutiliated Java – I’m still a little bitter towards GXT!). Keep up the good work.

, ,

No Comments

GXT is cool, but painful

Let me start by saying I’m completely on board the thin-client bandwagon. I think lightweight web applications are the future of everything from simple apps to enterprise software, and loved the premise of the Google Web Toolkit (GWT) from the start. So naturally when I had a chance to use GXT – Ext-JS’s framework that bridges their sexy JavaScript library with the promise of GWT development – I had high hopes. So far, I still feel the potential but can’t bring myself to love it quite as much as I want to.

The whole point of GWT is to take fragile and tedious web 2.0 development and make it feel like you’re actually building software: write one set of code that’s reusable and browser-agnostic, add handy modern language features like generic types and annotations, support a (relatively) fast change and deploy model, and best of all, at the end of the day still build good-old-fashioned HTML and JavaScript that runs in any browser: no Flash, Applet, Silverlight, or hardcore server-centric architecture required.

The core GWT guys get this and have made huge strides. The biggest beefs like IDE integration, richer hosted mode, and faster compile are all getting addressed. Integration with standards like Spring and Hibernate are already there and work amazingly well, if not quite out-of-the-box. For example, check out Giving GWT a Spring in its Step and Gilead.

By itself Ext-JS is also a great JavaScript library, with some of the best looking and most functional components out there. But so far their take on GWT misses the mark. The framework’s architecture – and more importantly, day-to-day use of it in real application code – screams JavaScript at every turn. Yes, I know this code will be used to build more code that runs in a browser at some point but it’s not supposed to constantly remind me of it! I don’t like switching between strongly typed objects and BeanModels full of string properties, having to bury myself in ten levels of CSS to make any slight component change look good in both Firefox and IE, or find their generic contortions that entertaining. It’s like the Ext guys are so lost in JavaScript that they missed the point of GWT.

The irony is that they’ve built a lot of tools that solve these problems individually quite well: there’s a BeanModelTag that will assemble reflection-like metadata when beans are sent to the UI and provide it on-demand using a factory from the bean, allowing you to switch between their models and the original beans as needed. The css for the components themselves is incredibly specific, well-organized, and for the most part consistent. The event framework, while not totally complete, is easily extended. These pieces just need to be put together with some level of configuration and convention so that day-to-day application code can focus on the look and feel instead of boilerplate MVC connectivity. In short they need to focus on how Java developers build applications, rather than how web developers can write the same kind of client code in Java. I’d love to be able to populate data in a UI component by doing the following:

  1. Write the server-side Java service
  2. Expose the service with simple annotation-based name and/or URL
  3. Create a client component that takes a data store and assign that store to the service endpoint

Ironically, this is the kind of thing that JSF components via Seam and Flash via Flex with BlazeDS do really well. The Ext components look way better than any JSF component library and are easily on par with their Flex counterparts, and that eye-candy appeal wins them a lot of ground (especially from those non-technical decision makers!). Architecturally, not depending on Flash or a heavy Java server puts them ahead of the curve: just put some implementation-level polish on it please!

I still have high hopes for GXT 2.0 which is currently in preview. The project I’m working on is standing by on 1.2.3 for now but we’ll switch over eventually and see how it goes.

, ,

61 Comments