The JSF Bottleneck
New Sakai tools are meant to use JavaServer Faces (JSF) to output the HTML people see when using the tools. We've been using XSLT to do the same thing in Stellar. I'm having some real difficulty with JSF as a user interface designer.
I was initially optimistic about JSF. Using standard Sakai tags to create HTML meant that if everyone uses JSF, it will be fairly easy to standardize UI elements in Sakai. And if we were to change one of those elements, a Java programmer could change the JSF tag. The HTML output would change in all Sakai tools.
But as we approach actual tool developments I've got some real problems with the technology. In JSF the HTML that is rendered is buried in Java code. There are lot's of skilled XHTML/CSS writers in the world, but most of them aren't Java programmers. So as a UI designer, if I want to change the HTML that users see, I need to communicate that to a Java programmer and wait for them to make the change. Using XSLT I could make those changes easily on my own. So by using JSF we've got this really inefficient workflow, where Java programmers, who are usually really busy doing other stuff, are also the gatekeepers for most UI changes.
Compounding the inefficiency, in Sakai we are planning to use a shared library of Sakai JSF tags. That means in order to get the HTML output modified, I need to write up the request and send it to a programmer I've never met, and who is also really busy working a variety of Sakai jobs.
It seems like we need a better way. I'm committed to outputting style guide compliant HTML, but I'm not sure JSF is the way to go.
I was initially optimistic about JSF. Using standard Sakai tags to create HTML meant that if everyone uses JSF, it will be fairly easy to standardize UI elements in Sakai. And if we were to change one of those elements, a Java programmer could change the JSF tag. The HTML output would change in all Sakai tools.
But as we approach actual tool developments I've got some real problems with the technology. In JSF the HTML that is rendered is buried in Java code. There are lot's of skilled XHTML/CSS writers in the world, but most of them aren't Java programmers. So as a UI designer, if I want to change the HTML that users see, I need to communicate that to a Java programmer and wait for them to make the change. Using XSLT I could make those changes easily on my own. So by using JSF we've got this really inefficient workflow, where Java programmers, who are usually really busy doing other stuff, are also the gatekeepers for most UI changes.
Compounding the inefficiency, in Sakai we are planning to use a shared library of Sakai JSF tags. That means in order to get the HTML output modified, I need to write up the request and send it to a programmer I've never met, and who is also really busy working a variety of Sakai jobs.
It seems like we need a better way. I'm committed to outputting style guide compliant HTML, but I'm not sure JSF is the way to go.
posted by Ben Brophy at
4:42 PM
