java.sun.com has posted a new article, "JSFTemplating and Woodstock: Component Authoring Made Easy" by Ken Paulsen, Jason Lee and Rick Palkovic. The article shows how to use the JSFTemplating and Woodstock projects to make JSF components with only two files: a .java sourcefile (with annotations) and an .xhtml template. In addition to providing a much (much) easier way to write JSF components, this technique is likely to become part of JSF 2.0, which has ease of component development as a high priority.

Finally JSF component creation is beginning to look a bit more like Tapestry. ;-) Still seems a bit clunky in a few places. For example, there are a lot of calls to "getPropertyValue" (in each of the getters) and some pretty hideous and error-prone code for "saveState" and "restoreState" in the UIComponent. I would think that all of those operations could be handled automatically by the framework (using the @Property and maybe other annotations as hints).

I think they are on an excellent road with this. I agree with the poster before me, the save and restore state and the setter and getter logic should be hidden via annotations. But definitely they got many things right this time one controller -> the component one renderer -> in a templating language I just wonder how to implement components with childelements with this approach, probably there is a helper function which triggers some child render code.

I just wonder how to implement components with childelements with this approach, probably there is a helper function which triggers some child render code.

In this implementation, child elements (components) are declared just as you would declare them in a page: If you meant, how do you render the user-specified children... you are correct, you can either render the child element by id: (the id can be an expression, btw). Or you can iterate through the children and render them as shown in the previous TSS article, also shown in project Scales (look at renderChildren.jsf): https://scales.dev.java.net/source/browse/scales/trunk/sources/src/resources/templates/ This could still be optimized more... Scales gets around this by using a "ui:include" in each file that wants to render all its children.