Tomorrow Comes Today

Das ZK Framework hat in unsere Projekten bereits seine Stärken und seine Schwächen zeigen können. Letztere liegen insbesondere in der Performance und der Cross-Browser-Kompatibilität, wobei letztere zumeist auch eher ein Performanceproblem ist. So sind mittelmäßig aufwändige Oberflächen in normalen Browsern wie IE7 oder Firefox 3 nur passabel nutzbar. Im IE6 mag man gar nicht mehr irgendwo klicken. Im Safari 4 oder IE8 hingegen, geht alles relativ flot - vermutlich wegen der dort neu eingebauten JavaScript Engines, welche primär auf Geschwindigkeit hin optimiert wurden.

Sollten die Probleme also die Einsetzbarkeit nicht  überwiegen, kann man sich auf viele spezielle Controls freuen. Besonders bemerkenswert finde ich die Spreadsheet Komponente, mit Rendering von Diagrammen, Formeln usw. Entsprechende Komponenten im Open Source Bereich sind nicht allzu weit verbreitet. Ebenfalls dehr schön und umfangreich ist die Kalender Komponente, welche irgendwie durch den Minimalismus und das hellblau an Google erinnert.

Ich bin gespannt, wo wir die Komponenten mal einsetzen werden.

Gestern wurde mir das Tool FindBugs™ empfohlen und nun werden wir es in den nächsten Java Projekten mal testen. Es verspricht anhand sogenannter Bug Patters Fehler in Java Quellcode zu finden, z.B. geöffnete aber nicht geschlossene File Pointer oder abgefangene aber nicht behandelte Exceptions. Für die einfache Nutzung gibt es ein Eclipse Plugin, welches alle gefundenen Hinweise und Fehler in den Warnings mit anzeigt.

As we are planning and prototyping a new technology for web based business applications at form4, I am constantly looking for future proof components for not only the use case but the business case view.

So I started with a little research abount workflow engines like jBPM and ended up with BPEL and some articles about this language. Well, one interesting aspect is the business process perspective and a second is the independence of the implementation technology.

For some reasons we focus on MDA by using UML for modelling and Java J2EE for the runtime and so I was looking for engines which are able to supply those languages: UML -> BPEL -> J2EE. So I found some insteresting articles: MagicDraw is going to support BPEL, jBPM announced an alpha release of a BPEL support and something about BPEL vs. Java writte by BEA and IBM.

But still open: the prototype. But I had some tries with jBPM - for my desperation not that successful as expected, but I will give it another try.

A while ago I got the requirement to internationalise an application for creating and organising offers. As I found out how complex the formatting of dates and numbers is, if you are dealing with different countries and languages, I was quite happy that there is something like Java Locale.

So I realized that it seems to be common to write out a price in Euro with a Euro-Sign within the European Union and with EUR instead outside Europe and the similar with US-Dollar. Furthermore the position of the currency sign, the separator character for fractions, the space (or no space) between sign and value and the number of fraction digits are quite different per country or language … I was a kind of fascinated about all that details. All for all that you can easily use the Locale in combination with Currency and CurrencyFormat.

Perfect - I thought till today. So how should we deal with a Japanese locale, which should format and display prices in Euro? Well, probably use the instance of CurrencyFormat with an ISO sign, which allows using an individual currency. Wrong! The Euro-price with the Japanese locale is rounded to full numbers without fraction digits - but with by showing EUR as currency. So there is no way around, as setting the currency, the minimum fraction digits and the maximum fraction digits of the CurrencyFormat instance manually by using the default values of the used currency.

Now it works fine. The price is shown in the right currency, the format of the price value depends on the currency and the position of the sign, the space and the separator character are dependent on the used locale.