Announce: Guise framework addresses JSF shortcomings

Question

JSF developers may be interested in learning of the release of a new framework named Guise(TM), which is now available free for development use:
http://www.javaguise.com/
I've been involved in the JSF forum for many months, as I spent countless frustrating hours trying to coax JSF into doing what I believed were simple, obvious things. As you can see on this forum, I've written a whole new value-binding expression syntax and framework just so I could pass parameters to methods. I've had to rewrite several JSF renderers just so the output it creates would not break my XHTML files. I've had to create a new component and associated framework just to upload files. I've kept the JSF community updated with my progress, but eventually I found myself rewriting the JSF framework more than I was writing application code. Guise(TM) is the solution I created for my JSF problems.
I'll admit that I first approached JSF with the wrong mindset, thinking that it was some sort of procedural scripting language like JSP. I soon adopted a component mindset whole-heartedly, only to be disillusioned: although JSF may claim to be definition-file agnostic, in reality it was built on top of JSP and jumps through a thousand crazy hoops just so people can define their components in JSP. Hans Bergsten infamously advocated (see http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html ) dumping JSP to save JSF, but even getting rid of JSF would still leave a framework that scatters type-unsafe strings throughout the source code and multiple configuration files, and provides wildly inefficient event delgation through many error-prone levels of an impotent expression language. That's not even considering finding the right combination of component IDs so that I can send back a validation error that will appear in the correct location on my web page.
I was getting ready to recommend to one of my clients a framework for their redesigned web application. I pondered what I would recommend---JSP+EJB? Struts? JavaServer Faces? In the end I realized that none of these provide anything close to the simple, safe, robust UI frameworks we're used to working with on the client. I wanted something that can be used like Java Swing, yet is simpler and more elegant, and uses generics. Since I was calling the shots, I decided that I wanted the UI to work on the client or across the web with no code changes.
So I wrote Guise(TM)---a graphical user interface framework in Java designed from the ground up to be both simple and elegant. Consider this example "Hello User" program, available at http://www.javaguise.com/demonstration
public class HelloUserFrame extends DefaultFrame
  public HelloUserFrame(GuiseSession<?> session)
    super(session, new FlowLayout(Orientation.Flow.PAGE));
    getModel().setLabel("Guise\u2122 Demonstration: Hello User");
    Label helloUserLabel=new Label(session);
    helloUserLabel.setVisible(false);
    add(helloUserLabel);
    TextControl<String> userInput=new TextControl<String>(session, String.class);
    userInput.getModel().setLabel("What's your name?");
    userInput.getModel().setValidator(new RegularExpressionStringValidator(session, "\\S+.*", true));
    userInput.getModel().addPropertyChangeListener(ValueModel.VALUE_PROPERTY,
        new AbstractPropertyValueChangeListener<String>()
          public void propertyValueChange(PropertyValueChangeEvent<String> propertyValueChangeEvent)
            String user=propertyValueChangeEvent.getNewValue();
            helloUserLabel.getModel().setLabel("Hello, "+user+"!");
            helloUserLabel.setVisible(true);
    add(userInput);
}No, this isn't Swing---it's Guise. The above example is all type-safe; the only hard-coded strings for this example is a declaration in the web.xml file binding the class to a navigation path. Forget "backing beans". Forget unsafe strings littering a multitude of configuration files. Try Guise, and you be the judge.
Here are some reasons you may like Guise:
* No JSP!
* Allows the web equivalent of modal dialogs.
* Quick and easy setup.
* Elegant ultra-MVC, with encapsulated models and controllers. No need for complicated backing beans and inflexible expression language---just use Java like you normally would.
* Instantiate components, plug in validators, add action listeners, and report errors directly instead of using cumbersome, error-prone, and type-unsafe strings scattered in various configuration files and source code.
* Java generics supported throughout.
* File uploads built in.
* Customizable, robust, authentication and authorization built in. Client-based authentication and login-based authentication can be seamlessly intermixed.
* Buttons are rendered with real buttons that allow icons and other rich content, and automatically work around the IE button bugs.
* Output is 100% XHTML compliant, with automatic downgrading from content type "application/xhtml+xml" to "text/html" for buggy clients (such as IE 6) which crash when the W3C specification for XHTML content type is followed.
* Validation errors are automatically associated with components, and appear automatically on the web page. An error dialog box is also presented indicating the errors.
* Internationalization is built in. Each application is aware of its supported locales and the selected locale of each session. Set a control model's resource key, and the correct value will automatically be loaded at runtime.
* Parameters can be sent in the URI query string.
* Multiple components can share the same model.
* List selection controls implement the java.util.List interface and support generic values.
* The Guise framework is thread-safe.
I realize that although it's likely the release of Guise will be of interest to the JSF community, in-depth discussion of the framework is probably off-topic for the JSF Forum. I welcome further discussion of Guise, along with inquiries, at [email protected] . Further information may be found at http://www.javaguise.com/ .
Sincerely,
Garret

Answer 1

Ed,
I appreciate your innovation in creating a new
Framework, I'm of course very interested to hear
specifics about why you chose to do so. Which
shortcomings in JSF exactly are you trying to fix?Thanks for the concern. If you look through the posts I've made to this forum, you'll get an idea of the heartache I've went through with JSF. Let me give you an overview. (I've provided appropriate citations to the related forum discussions.)
Iteration
One of the big newbie complaints you'll hear is that JSF won't work with JSTL---in particular, the JSTL iterators. I ran into this problem early on, and decried the lack of no iterator replacement. Adam Winer explained all the "pain... pain... more pain" it would take to create an iterator in JSF that would work with other components. After I became experienced with JSF and dug through the source code for months, I pointed out that UIData already goes through all this pain and needs to be refactored---UIData is really a UIIterator with a tad bit of table-specific stuff thrown in. http://forum.java.sun.com/thread.jspa?threadID=557278
But the complaints and debates about iteration reveal a more fundamental problem with JSF. At its heart it is declarative---a fault it inherits from its close relationship with JSP. Tables, for example, are defined as a static relationship defined forever-in-stone in (for example) a JSP. Because we all want dynamic data in tables, JSF allows us to declare a programmatic relationship between table rows and the table, resulting in secret counters that get incremented and decremented in the background as rendering occurs, along with associated bugs in nested tables. A render phase is simply not the place to put dynamic application logic, but in JSF that's the only place to put it if you follow the paradigm. And you must do the same strange variable counts in the the other phases, just so you can wind up with the correct bindings for the correct row.
Because JSF forces application logic into the render phase, I have to create something like a UIAssignment component that pretends to be a static component in the hierarchy, yet really performs variable assignment as JSF goes through the rendering process. I have to rely on the implementation rendering in the correct order, and I have to add with intricate logic to work around hidden/visible settings that might alter the rendering procedure and hence defeat the assignment algorithm. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=576178
Guise is not built on top of JSP, and hence doesn't force one to put rendering-related hacks into the application code. Check out the elegant Guise table model, for instance. It's very similar to the Swing table model, but simpler, more elegant, and with generics. Rather than play with counters and rendering in the application logic, you can just reference Java objects as you would normally. This entire issue of iteration is also related to the "Loose, Late Binding" issue and the "Impotent Expression Language" problem, which I discuss below.
Loose, Late Binding
Because JSF uses the "pretend not to be tied to JSP but support JSP in the archictecture" paradigm, the components are so uncoupled from the application code that any event logic must use a separate expression language. This language is not checked until runtime. I could put the string "Bill Murray" in an expression, and I'd never know about the problem until someone tries to access that page. Similarly, any expressions are so loosely bound that I don't know to what extent they actually work with my code until I start up the web server.
What happens if I want to respond to an event in JSF? Well, first I have to create a "backing bean," a special mediator to help my components and application work together. Then I have to create an un-typesafe string in a non-Java language that binds something that happpens on the component with the backing bean, which will in response do something with my application. Something like:
<h:commandButton action="#{myBackingBean.doSomething}" value="Test"/>Then (as if this weren't enough) I have to find some configuration file somewhere in order to define my backing bean (it doesn't work automatically). Needless to say, this definition also isn't typesafe and is not verified until runtime. All this just to respond to a button being pressed?
Guise doesn't need an expression language, backing beans, or backing bean configuration files. If I want to repond to a button being pressed, I just listen for it---right in the Java code:
myButton.getModel().addActionListener(...)Everything is typesafe (with generics, I might add). If there's a syntax problem, you'll know it when your program doesn't compile. Your code becomes much more efficient because the expression string doesn't have to be parsed, a variable-binding object doesn't need to be created, and a backing bean doesn't need to be looked up every time the page renders. It just works like you expect Java to work. Simple and elegant.
But the loose, late binding doesn't stop at the expression language. Binding components to IDs in faces-config.xml isn't typesafe. Assigning renderers in faces-config.xml isn't typesafe. In fact, even programmatically creating a component at runtime forces me to use some arbitrary string that isn't tied to anything except some lookup map somewhere that I hope has been properly configured by faces-config.xml and the various components and renderers. Changing component properties at runtime requires several levels of un-typesafe string processing. String, strings, strings---JSF brings Java back to BASIC, as it were.
If I want to create a component in Guise, on the other hand, I do it like I'd create anything else in Java:
Label=new Label(session);If I want to associate a controller with a component in Guise, I'm not just passing around opaque strings. Here's a line out of XHTMLControllerKit:
registerController(Label.class, XHTMLLabelController.class);
Impotent Expression Language
It's bad enough that we have to mess with expression languages, but the JSF expression language is impotent that I can't even pass arguments to methods! (The argument that JSP doesn't allow them either falls on deaf ears---JSF isn't tied to JSP, right?) Doing simple things like selecting an item from a list becomes virtually impossible (if you want to keep your elegantly-factored backend code) without argument passing. That's why I was forced to create an entire new expression language on top of JSF-EL just to allow parameters to methods. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=561520 And (combined with the iteration problem, above) I had to create a UIAssignment that pretends to be a component yet really performs variable assignment in the background, using my extended JSF-EL. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=563036
Internationalization
Support for internationalization in JSF (and even in Swing) is provided in a sort of ad-hoc, last-minute manner. Guise has internationalization support built in from the ground up. Each component model can be given a resource key, which will automatically get the correct data based upon the session locale.
Guise handles internationalization of component layout automatically as well. Check out the internationalization demo at http://www.javaguise.com/demonstration ---just by changing the session locale, the entire component hierarchy reorients itself automatically and loads the correct resources. That's done with one line of application code!
File Uploads
JSF doesn't support file uploads, and I had to concoct an entire file upload framework for JSF. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=464060
Guise has elegant, validating file upload support built in.
In the end, I just wanted to write an application for the web like I would for Swing, without resorting to a mindset of a couple of decades ago when typesafeness was unknown and event delegation wasn't elegant. Since we have Java 5.0, I also wanted to use generics. I just wanted to program using best practices rather than setting up endless text-based configuration files. I wanted Guise(TM). So I wrote it.
Also, would you consider joining the JCP expert group
working on JSF? The whole point of the JCP is to
allow people with big ideas like yourself to help
grow the core platform.On 21 October 2004, I wrote on this forum, "I'm willing (and eager) to join the expert group and put in my effort to help effect these changes in the specification..." http://forum.java.sun.com/thread.jspa?forumID=427&threadID=565052
I then requested directly to join, and Roger Kitain replied that, "Currently, the group has quite a few members, so I'm not adding any more members unless their background is an exceptionally good fit." On 24 January 2005 I provided extensive coverage of my qualifications to both you and Roger.
On 17 March 2005 I indicated I was still willing to join, but Roger had already pointed out the catch on 7 February 2005: in order for me to spend my time and provide my expertise to contribute to the advancement of JSF, I must pay Sun $5,000. It wasn't enough that I was offering my services for free---Sun wanted me to pay them to allow me to contribute to bettering JSF.
I hope this overview answers your question about the shortcomings of JSF. If you have any more questions, I'll be happy to answer them. You may be interested in reading more about the basics of the Guise(TM) framework at http://www.javaguise.com/overview and constrasting the Guise approach to that of JSF.
Sincerely,
Garret