New York City: AjaxWorld

In March I’ll be in NYC for the first time of my life! I am going there because my talk for the AjaxWorld conference was accepted. I am really looking forward to the conference, since there are lot’s of great talks.

My talk is about… yes, JSF. The title is “Writing AJAX-Based JSF Applications with Apache Trinidad and Facelets“. See here for more details.

Apache Member

I was invited by Lars Eilebrecht (behalf of the Apache Software Foundation membership) to join the membership of the ASF.

I’m really honored and flattered about the fact! And yes, I did accept the offer

Manfred Geiler, MyFaces PMC chair, is now also a new ASF member.

Really cool news, for me. Like a X-mas present

IBM is using Apache Harmony

Today I found a very interesting post, from Geir.

He is referencing to an announcement, that IBM is using Harmony in their JDK 6 impl.

Here is his original post.

Since I think, that this is a very cool post, I am telling

Apache MyFaces Orchestra – simpler XML config!

Simon Kitching created this Orchestra enhancement, and he (of course) implemented it.
What does that mean ? It actually simplifies your XML configuration!
In the “past” (well, Orchestra is pretty young (but stable)) a bean looked like:

<bean id="googleMapBean" class="net.wessendorf.faces.starter.view.controller.GoogleMapBean" scope="conversation.manual"
    orchestra:conversationName="googleMap" p:userService-ref="userServiceImpl">
   <aop:scoped-proxy />
</bean>

Now, it looks like this:

  <bean id="googleMapBean" class="net.wessendorf.faces.starter.view.controller.GoogleMapBean" scope="conversation.manual"
    orchestra:conversationName="googleMap" p:userService-ref="userServiceImpl" />

Just a single line of XML… Not a big deal, but in large applications, you actually benefit from it!  I updated FacesGoodies, to reflect this change!
Next thing is to use Spring’s JavaConfig (Spring 2.5), to get rid of more XML.

Thunderbird vs. Gmail (Desktop vs. Web)

I am using Gmail for all of my (Apache) mailing lists, my private stuff, and sometimes I write emails to team-mates via my private Gmail account.
For 99% of my corp. emails, I am using Thunderbird, which is a FAT CLIENT.

I like using the Web-based email, but sometimes, the traffic is slow (depends on your connection, sure) and than… switching folders or searching can be a PITA. That is not the case in Thunderbird. That FAT CLIENT is working offline too.

Now there are “persistence frameworks”, such as Google Gears, which offer your a great deal to run your web-app offline.

But even with that, sometimes it just feels better to use a FAT CLIENT, IMO.

Using Web-Mail is common; word-processing or spreatsheets are new, but they are more and more used, in an online version.

All this is OK, the move is from the desktop to the WEB. Fine so far, but I’d never want to use my IDE (JDeveloper and Eclipse) via a Web-Browser
That would be just too much. I hope that this isn’t the next trend

GMail supports IE 7 and FF2

This morning I was a bit surprised, that my GMail UI has changed a bit… they updated it.

However, the more interesting news is, that it looks like they treat IE7 and FF2 as first class citizens for their UI-updates.

Form an Ajax point-of-view, this is really interesting since in IE7 you have XHR support w/o ActiveX.
This fact makes an upgrade to IE7 more reasonable.

Oh no, I wasn’t surprised on the FF2 only fact, but a little bit on IE7.

But… makes sense for me!

Java’s NumberFormat Bug

I ran across this bug, when I had to verify that the Trinidad NumberConverter is able to parse currency strings for the France locale (fr_FR).
Why not, I thought…..

Here is a bit simple code:

String value = "12 345,68 €";
NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
ParsePosition pp = new ParsePosition(0);
Number n = (Number) nf.parse(value, pp);
System.out.println(n);

I’d expect that the System.out.println() prints a number (12345.68), but it is not the case!The problem is, that the currency string (“12 345,68 €”) contains two spaces, but for the fr_FR locale the parser wants this:

• the thousands separator is non-breaking space
• the space between the “number” and the EUR-symbol is a regular String

In the end, it means, that I have to create a parser, in order to use the Java build-in one

A hack demonstrates, what the Java-parser expects, for France Locale (true for Finish as well):

String value = "12 345,68";
value = value.replace(' ', '\u00a0');
value += " €";
NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
ParsePosition pp = new ParsePosition(0);
Number n = (Number) nf.parse(value, pp);
System.out.println(n);

That finally prints out the expected number. Wouldn’t it be great, if the parser would accept a non-braking space in front of the €-symbol?

The bug is still open…