Blogging about ICEfaces

One of my favorite software development frameworks - ICEsoft's ICEfaces started a blogging contest (one of the prices is an iPad - nice since my fiancee probably won't approve the budget for a gadget like this).

What I really like about ICEfaces (in comparison to trinidad, what we've used before):

• Nice looking components (probably not the most important one from a development point of view, but hey, that's what sells the products and thus pays my salary :-))
• Active and Helpful forum (http://www.icefaces.org/JForum/search/filters.page). This cannot be valued too high - in my opinion. I'd say roughly 70% of my questions could be answered by searching in the forum and checking the answers people with similar problems had - the other useful source is the public ICEfaces JIRA
• Consistent attribute naming
  Trust me, this is really a big improvement comparing it with something like trinidad. When the attributes all are named consistently it is very easy to exchange components (replace a dataTable with an panelPositioned or a panelSeries for example, switching between inputText and outputText etc.)
  
• Awesome features that come out-of-the-box
  - Push Server
  - Drag and Drop
  - and all the other nice things that can be seen in the component showcase
  

So, you can expect quite some posts about it and of course also my unfiltered opinion.

I'd like to kick it off with my first impressions after having looked at the (fairly new) composite component suite (http://composite-component-showcase.icefaces.org/icefaces-composite-comps-showcase/showcase.iface):
We just recently got access to it (licensewise) and this will really save us some time in future development. The new tables, dual lists and layout components look especially helpful for our current project. I'm really looking forward to using them as soon as possible.
In the past we've implemented something like filterable column headers on our own - we've got a working blueprint for this now, but it requires quite some knowledge about the surrounding program logic to get it successfully integrated in a complex screen.
Dual list won't save too much time (given, that you can also use two single lists and some backing bean data storing and controller methods) - but I'm always a big fan of writing fewer code.
The layout components will definetely play a big role concerning the sexy-factor of our application - and it is always nice to have a better looking UI for low costs ;-)

So, that's it for now - more will come quite soon.

Injuries, Injuries, Injuries

Ok, that's it! Third week - third injury. I'm officially getting old...

Two weeks ago I sprained my right ankle - not too badly (it was worse some years back) - but still bad enough (thanks to my great Nike LeBron III Sneakers that I bought in New York last summer - the lacing is already broken which caused this)....

Last week I dislocated my right pinkie - looked really disgusting. Coach came over and moved it back into place - he also told me to see a doctor the next day - which I didn't.

Two days ago I managed to sprain my hardly healed right ankle AGAIN. OUCH! That hurt - but it is getting better and I'm looking forward to next monday's practice.

So currently I'm playing with a slightly unstable ankle and a right pinkie that I'm "buddy taping" (http://www.utahmountainbiking.com/firstaid/finger.htm#Dislocation) - my shooting percentage is down quite a bit since I started doing this :-)

When something else happens in next week's practice I'm gonna sit out a couple of weeks and focus on healing until the wedding. Damn - suit fitting day is in 2 weeks and I still have to lose 5 pounds (preferably fat).

Bought our wedding rings

That's it - we're officially getting serious about this marriage-thing.

- after having booked location, dj, priest, church, catering, photographers, accommodation, florist and wedding cake
- after having sent out save-the-date cards and the invitations
- after having prepared our online wish-list (www.wunsch-galerie.de -> I strongly recommend this site - it's free and it is linked to the most popular online stores)
- after having bought suit (for me) and dress (for my fiancé) - together with shoes, belt and misc. accessoires for her
- after having finalized the detailed planning and decoration
- after having participated in 3.5 dancing classes

...we finally made it to the jeweler and ordered our rings (will hopefully be ready in 2 weeks).
They are made of white gold and my soon-to-be-wife's ring has a couple of diamonds in it - mine is just rhodanized and mat (everything else looked kinda gay...). Costs are at around 1,300 euros for both - which is surprisingly within our estimates.

I think actually getting married is the easier part of the whole operation... (or is this just what I'm hoping?)

Practice No. 4

So, we just had our fourth practice yesterday and things are starting to click:

Our level of fitness and stamina has improved consistently - you want evidence?
Some of the guys on our team have been on vacation the past two weeks. During yesterdays practice it was quite obvious who made the fastbreak drill for the first time - those were the guys panting heavily after 5 minutes. The rest of us were just fine and could complete the practice without collapsing ;-)

After having worked on fastbreak plays and 6 different options for our early offense we don't seem so confused anymore while on the court. We press the tempo on every possession and everybody knows his spot(s).

One personal downside for me were some more bruises on my forearms - I am playing in the post against the big guys (since I'm not shooting the ball too well) and they make me earn every inch.

Looking forward to monday's practice...

New Coach for our Team

Well, recently we got a new coach for our basketball team after having finished 5th in our league last season (some really stupid losses included).

So, new season, new coach.

Our target is to advance 3 leagues within the next 5 years (which means to finish 1st or 2nd every second season in the new league).
Some could say that this goal is quite ambitious - I thought the same before our first practice two weeks ago. Then we had the hardest workout in my basketball life so far - I was impressed.
I was even more impressed to find out on the next practice that it could get harder - and again harder in the next practice. After having run for 2 hours at nearly full speed I skipped my usual post-practice shootaround and headed straight to the showers - to make it there as log as I could still walk upright.

So, today is our fourth practice session and the tryout period for the team is nearly over - 30% of the players have already left and our team seems way fitter than through all of the last season.

The future looks promising...

Java Server Faces and added complexity

Having worked lately on an extremely generic component for one of our JSF (ICEfaces) based products I must really say: You have to jump through a lot of hoops because some useful functionality is missing in JSF. This list is not meant to be complete. It's just what came into my mind today:

• No parameters for method bindings
• Insufficient enum support
• Constructors for Pojos
• Dynamic method/value bindings using the Expression Language
  

No parameters for method bindings
I really think this is the worst one - anyone who ever tried to call an action with a parameter came across this issue and used one of the workarounds to actually get it done:

1. Create an additional parameter object and work with f:setPropertyActionListener (only works for actions and not for parametrized getters)
2. Use the Map-Hack: Create a Bean that implements the map interface and put all your fancy business logic in the get method - you can call the get method with one parameter (usually the key for the entry you want to access). I must admit I have used this once or twice and it gets the job done - needless to say that it's bad design and I've even read a couple of times that it has some pitfalls (that I haven't encountered so far).
3. Create a map property on your backing bean: I actually think this is the only valid approach (ok, the parameter object is fine for actions as well) if you need to access data in a parameterized way. Your parameters become the key(s) for the map property and the object you're needing is the value. This has the only downside that you have to initialize the whole content of the backing bean's map when the data is displayed to the user - whether it is really needed or not because you can't control the calling of the getter from the backing bean.

Insufficient enum support
So maybe I'm wrong on this one but I couldn't find a simple way to use enum instances in JSF pages. I couldn't create instances of an enum "on-the-fly" to access certain data or provide it as a parameter. Here are two ways to handle that:

• Completely abstract from enums in your pages and use String data fields instead (You would then have to transform the String objects into Enum constants on demand)
• Use a utility bean in that populates Map members on startup with all the elements of your enum. You can then easily get the enum instances by using the members fo this bean with ['enumInstanceName'] to actually get the objects you want right from the start

Constructors for POJOs
Say you want to provide not just a simple parameter/value to your backing bean but already an object (to limit the number of properties for your backing bean) - I didn't find a way to initialize an object from a JSF page and fill some properties. There is some sort of workaround with providing a dummy managed bean for this - the JSF framework takes care of initializing it when you access it for the first time - but it was really a drag. I tried to use this with a request scoped bean - but it kept the value during partial page submits (because for JSF a request ends only when you leave the page - it spans over different partial page submits). So I needed to cleanup the request scoped bean after having retrieved the data. I didn't really find a solution for this and sticked to using multiple properties in my backing bean.

Dynamic method/value bindings using the Expression Language
What I mean by this is: Let's say you have a bean 'A' with the String properties 'a' and 'b'. It is now not possible to use one input text component and link it to either one of them depending on a boolean value (e.g.: #{not empty bean.c ? bean.a : bean.b}). The only way to achieve this is to duplicate the text component and use the rendered flag or create a dynamic value expression in your backing bean and set it on the component programmatically.