JSF Controls

Well we chose JSF because it provides and easy method for developing custom controls. I’m not sure what convoluted definition of ‘easy’ the JSF spec uses but I think there on crack. Having used C# custom and user controls JSF’s definition is way off.

First of all you can’t just create a control and edit it with a WYSIWYG editor. C# only provides this for user controls. Which are in essence a set of controls nested together with C$ backing code.

Now with C# custom controls you basically can just write HTML to a HTTP response. Any script kiddy will feel right at home doing this. Now for a JSF control? Well first you have to define a tag class Tag.java. Here you create the setters for the properties of the tag. Then you create .java which extends UI Component now you have to implement all the abstract methods and define the family, component name, and several other things. Now finally you can define the last class which implements another interface Render.java. This class tells JSF how the control gets rendered on the screen.

So were done right? Sadly no. Now you have to define a TLD for faces to read and make sure it’s in a jar on the class-path or in WEB-INF.

Oh wait! We forgot to add the render to the faces-config.xml. Ok so now it the moon, sun and stars are aligned your control should load.

See? Isn’t JSF so wonderful and simple! *barf*

Never build your house on sand

Well for those of you who do not know me I will give you a little background. I just started a position at a new company a few months back. This was a huge change of pace for me. I went from working on simple boring design-less java based modules to working on an agile team. Needless to say it has taken more than a little getting use to.

Now why is this post entitled “Never build your house on sand”? Well that is simple. My primary role on our team is developing our UI (User-interface). Now the first problem is that our UI is being treated as a 3^rd party add-on to our API. The problem with this is that the API is still being developed. Its not that we are closing up the loose ends and polishing the API we are still working out the requirements and object model.

Now I know the first think your thinking; well agile development embraces change so we should as well. While I do agree with this idea as it stands now this is not how it is turning out.

Most people in our group are experts on the API portion of the product (this is version 5 w00t). While sadly I’m the only one up to speed on how the UI works, and sadly we don’t have the time to bring the other guys up to speed because they are moving the API forward and are needed there.

So what does this all mean? Well every time something in the underlying API changes; method signatures, object relations, etc, the UI breaks. Yes I have unit tests and functional tests that are run via out continuous integration process. Instead of having the developers that make the changes to the API fix the test that broke I get “Hey broonix I broke some of your tests, can you look into it?”.

Well there you have it. There is my beach and the house I’m trying to build on it. Every day seems to be a constant battle of adding new walls to the house and making sure the old ones have not fallen down. No there is no moral to this story but hopefully I’ll have the answer soon.