JSF 2.0 - some more thoughts

A better DataModel

Something that should go in is an improved DataModel, akin to Trinidad's CollectionModel (see my blog posting about backing the CollectionModel with Seam). This should support paging (Trinidad's CollectionModel is, imo, a bit off target here as the CollectionModel isn't informed of when to page, and how much by - you can make a good guess, but...) and sorting (Trinidad have got this right on the mark) such that if you use a JSR-299 akin product it can easily give you database backed (aka high performance) paging and sorting. Another interesting feature of Trinidad's collection model is that

Gavin's response to this was that it wasn't RESTful - well, if it's being done without AJAX it should be, and, if it is - well, the challenge is then to make it RESTful!

Niggles

There's been lots of great feedback on the JSF 2.0 proposal draft, most of which has focused on the big ideas, but of course there are small niggles to be addressed to ;)

• saveAttachedState and restoreAttachedState automatically iterate over any java.lang.Iterable and attach/restore the state of each item (currently it just does this for lists)
• AFAICS the spec doesn't specify if, when the property is a String, whether a converter specified for class String should be run (MyFaces runs it neither way, the RI (1.2) runs just getAsObject())
• There should be convenience methods to render a JSF view programmatically - this would set up the lifecycle and render the view - after all, you can easily use an alternative ResponseWriter to writer to a StringBuffer. We do this in Seam to allow you to send an email (templated using facelets) from your backing beans - but, unless the request originated in a JSF request (it might be from another source like an MDB, a timer), we have to create our own JSF context.