Archive for August, 2008

JSF 2.0, a glance

27 August 2008

Having been recently thrown into the deep waters of JSF and Facelets it seemed natural to do an evaluation of where this technology is going. JSF is currently at version 1.2. Version 2.0 is scheduled for release with Java EE 6. So what goodies will this bring us?

The main goals of the revision is to make development easier by integrating into the core system many tools/frameworks which were built on top of previous JSF versions. Ajax support, facelets-like templating, improved development support and better performance are all things that are mentioned in the specifications.

These are the highlights of what is coming:

I’m sure everyone is familiar with Ajax. JSF 2.0 includes Ajax in its life cycle and offers more direct support for its use. The view state can now be partially updated to reflect that only part of the view has changed. Ajax will make use of the new resource handler scheme. This isn’t very exciting in and of itself. A natural progression in the way one would expect this technology to mature.

Facelets is another technology needing to be incorporated into 2.0. Facelets allows us to define our pages in a different way by using XML and templating. The way to write these pages is very close to the the way we already work, which makes it easy to learn. The added usefulness of templating allows us to write less cluttered pages. It also increases code reuse. The popularity of this approach and its obvious usefulness make it inevitable that this would be included in JSF 2.0. This is currently referred to as ‘page description language’ in the JSF specification. While the name is less exciting than Facelets it is accurate and there is no doubt that this is a welcome addition to JSF

Development for JSF is getting some support through the ‘Project_Stage’ feature. This is no more or less than a context parameter. Now many people are excited by this, but I don’t quite seem to share the sentiment. Theoretically this will allow for actions dependent on where the project is in its life. Is it in production, unit test, system test or development? The options are limited, though probably enough. What I am wondering is what it is doing in JSF. While there is a use for a setting like this, indeed it seems common in many disparate projects, it seems to me to be a higher level setting than JSF level. JSF should support it, but not claim it.

Another interesting feature is the Resource Handler. Resources are anything that could be included in a component that is required for the component to be rendered correctly to the user-agent. Think about images, JavaScript or css files. The Resource Handler enforces a structure on your resources which in and of itself just helps in organizing your project. This will also make it easier for component developers. They know exactly where to put or look for resources without having to know what application is using them. Locale and versioning are handled automatically. Another advantage is that replacing resources runtime will be much cleaner. No restart of the system should be needed.

There are some things about resources I don’t like however. First of all the specification only specifies a structure for webapps. Implementations for other platforms are even invited to do whatever they want. It seems an unfortunate choice since you really want a standard to be standard. Another is the relocatable resource. Now you can tell certain resources where they are supposed to be. Put the tag in the body but tell it to be rendered in the head. I don’t understand the reasoning for this. Perhaps if it is based on some conditional programming elsewhere on the page….but quite frankly your page is probably getting to complicated at that point. If something needs to be in the head (body, wherever), just put it there. I wonder if I am not missing some essential insight with which I will all of a sudden see what a great and useful feature this is.

One argument for relocatable resource is that components may wish to write things in locations which are outside of their direct knowledge. The head of an HTML document is an example. A component, possibly called by other components, could decide it wanted to change the head of a document. This is completely undesirable behavior. If the component is generic it should never bother with anything outside its scope. If it isn’t generic then its use is limited anyway and one could ask why it is even a component. Thinking specifically of style information I would say that this should never be overwritten at component level. Scripts can be included in the body and shouldn’t require anything beyond what exists in the component anyway. Apparently the community desires this functionality. To me it seems a harmful construct which should not be supported.

All in all I think JSF 2.0 will be an improvement of the technology. It has listened and learned from what the community has built on top of JSF and incorporated the features that were most used. As well it improves its internal workings which is never a bad thing from a user perspective. While I may not yet understand all the choices made it is obvious that the changes were well thought out and planned. Assuming the implementation is improved as well then JSF 2.0 will be pretty much what you want from version 2.0.

Jasper Floor

useful links:

Java developers en programmeurs zoeken is een hele kunst

2 August 2008

Hoe vind je een goede programmeur? Programmeurs hebben verschillende hobby’s, houden van verschillende soorten muziek, hebben verschillende meningen over politiek, enz. Je loopt niet zomaar een genootschap van programmeurs binnen waar je de mensen met de juiste kennis voor het uitzoeken hebt. Waar vind je dan die goede programmeur?

E̩n ding weet ik wel Рdat iemand vroeg moet zijn begonnen met programmeren om er echt gevoel voor te krijgen. Je moet als het ware kunnen denken in nulletjes en ̩̩ntjes. Als je als kind met een Atari of een Commodore 64 hebt gespeeld Рdan ben jij er als programmeur vroeg bij geweest.

Tegenwoordig wordt je niet meer gedwongen om te weten wat programmeren is. Vroeger, met Basic, kon je eigenlijk niet anders. Vele technische ontwikkelingen hebben die ervaring overbodig gemaakt. Er zijn nu allerlei mogelijkheden om het echte programmeren te omzeilen. De programmeur die wij zoeken deinst er niet voor terug dit soort mogelijkheden links te laten liggen, en écht diep in de code te duiken.

Maar ervaring uit het verleden is niet alles. Je moet ook in staat zijn om je snel nieuwe technieken eigen te maken, en je moet veel lezen om je kennis steeds te blijven uitbreiden. En natuurlijk moet je weten waar je je computer voor kunt gebruiken. Dat programmeurs soms lui zijn is eigenlijk wel eens een goede eigenschap. Ik geloof in het woord automatisering! Laat de computer het werk maar doen.

Terug naar het onderwerp. Waar zijn de developers die we zoeken? Als je dit leest zijn we misschien klein stukje verder… Neem eens een kijkje op onze pagina Vacatures.

Met vriendelijke groeten,


css.php best counter