JSF 2.0 Begins

JSF Spec Team led by Ed Burns has initiated the process for JSF 2.0, they made a wise move and decided to get feedback from the community. Everybody including myself has posted several opinions and suggestions to the JSF 2.0 wiki, the good thing is that the well known problems of JSF will be fixedin the next version. Personally I’m not happy with all the discussed hot Ajax stuff because there are more important issues in the core framework to be taken care of first.

JSF 2.0 is an important chance to dominate the Java Web Framework field, I’ve already posted my ideas to the JSF 2.0 wiki but here I want to discuss more.

* Client Side Validation
It’s already in JSR and probably JSF 2.0 will have it. In myfaces I’ve already created a %100 serverside compatible client side validation framework and as Ed mentioned in his blog, Martin Marinschek, the possible representative of Apache MyFaces in JSF EG will hopefully bring it in.

* More Powerful IOC
IOC container concept is a hot topic, while we are addicted to Spring, Guice, Pico or whatever in the business layer, I think with some improvements JSF could help a lot. The major missing features of JSF Container is construction injection and AOP support. My proposal for construction injection is;

 <managed-bean>
    <managed-bean-name>accountBean</managed-bean-name>
    <managed-bean-class>com.cc.AccountBean</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
    <managed-property>
        <property-name>accountService</property-name>
        <value>AccountService</value>
        <constructor-arg />
    </managed-property>
</managed-bean>

This way the AccountService bean will be given as the param of the AccountBean(AccountService accountService) constructor.

For simple AOP support, it’d be great to have the concept of interceptor like this, suppose you want to keep the audit logs of every persisted entity annotated with a custom annotation called @Auditable

 public interface AccountService {

    @Auditable
    public void save(Account account) ;
}

And here is the JSF IOC interceptor, inspired by spring AOP.

 public class AuditInterceptor implements javax.faces.aop.MethodInterceptor {

    public void intercept(MethodInvocation methodInvocation) {
        //do something before if method is auditable
        methodInvocation.invoke();
        //do something later
    }
}

And register in faces-config by;

<interceptors>
    <interceptor>
        <name>AuditInterceptor</name>
        <interceptor-class>com.cc.interceptors.AuditInterceptor</interceptor-class>
    </interceptor>
</interceptor> 

To enable the interceptor intercept the JSF IOC managed beans;

<managed-bean>
    <managed-bean-name>accountBean</managed-bean-name>
    <managed-bean-class>com.cc.AccountBean</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
    <managed-property>
        <property-name>accountService</property-name>
        <value>AccountService</value>
        <constructor-arg />
    </managed-property>
    <interceptor>AuditInterceptor</interceptor>
    <interceptor>TransactionInterceptor</interceptor>
</managed-bean>

This can be improved a lot by doing auto-proxy stuff like in spring, using a pattern to intercept that only matches some regexp, my idea is just to make the JSF IOC more look like a real IOC container like Spring.

* Flexible Lifecycle
Mostly JSF users complain about the unflexibility of JSF lifecycle. For example it’s a pita to skip the validation phase, the problem is that although the phase name is processValidations, the phase also does conversion first and then does validation. I think seperating this into two phases will make things easier and help to get rid of hacks like immediate attribute. See this proposal of mine. By adding an attribute like “causesValidation” to UICommands like CommandButton, page designer can set not to run validations for the corresponding button action behavior like a navigation case or a form clearing case.

* Transient attribute just like enableViewState in ASP.NET
In ASP.NET there’s a very useful attribute called enableViewState to decide whether the component’s state can be saved or not. For example you don’t need to save the state of many components in many cases, by a transient attribute page designer could decide to save the state or not to. Also in general I think ADF’s state saving method should be adopted when saving/restoring the state.

* Configuration without faces-config.xml
In my current project, we’ve custom annotations like @Bean,@PhaseListener and etc plus a custom maven plugin we’ve written to generate the faces-config.xml. What I would like to see is that a servlet listener or something else checks the classpath and gets the config info. This is already in JSR by the way.

These are the only important ones that come up to my mind now and the community already presented many more ideas to the EG.  group. As I mentioned JSF 2.0 has the potential to rock, I’ll continue keeping an eye on the process.

Comments are closed.

%d bloggers like this: