JSF Client Side Validators RELOADED

They’ve existed once, donated to myFaces and suddenly disappeared… Now JSF Client Side Validators are back to the city Well here’s what really happened. Actually me and Martin decided that it would be better provide similar client side validation support for the extended validators in tomahawk. So instead of using seperate client side validators, the ones already in the tomahawk will have enableClientScript flag which will enable them to validate at client side. I’m currently working on it; on my way since these seperate client validators once created have not been released so far, I’ve decided to release them at jsf-comp. Before doing the release I’ve added many features to the client validation library. Here are the currently supported validators.

1) Required Field Validator
2) Range Validator
3) Compare Validator
4) Regular Expression Validator
5) Length Validator
6) Integer Only Validator
7) Custom Validator
Validation Summary

And two views showing the client validation framework in action, one without popup and one with.

   

Key Features
1) Client Validation in JSF is also supported by Shale and ADF Faces however both use unattractive popups to display the validation messages. By default client Validators show the validation message where they are placed. However this is not mandatory, popups are also supported with an optional boolean attribute.
2) Client validators are extendable via the Custom Validator component, you can plug your own validator functions to this component.
3) Error messages are fully customizable, each validator can user their own message or read from a bundle.
4) Style of the validation messages can be managed through the style attribute.
5) Resource loading is done from the jar file so there is no need to use additional resources like js files, only thing you need is the jar file.
6) Validation Summary component allows the presentation of each validation message in one place.
7) Display mode is customizable which means space for messages can be reserved or created dynamically, also if set to none then the message is only displayed at validation summary.
Highlighting is supported, if set true then the components caused the validation is highlighted with color.
9) Implementation independency, client validators can be plugged to any JSF implementation.

UPDATE: 11.02.2007
The project is no longer under development but the successor of this library has joined Apache MyFaces.

Detailed Documentation and Download
* There is a very detailed documentation at jsf-comp.
* Both source and the distribution can be reached at jsf-comp downloads section.
* I’ve provided an example web application which can also be reached at downloads section.
* In addition I’ve updated my first entry on the client validators.

FacesTrace beta is out

It’s been a week since we announced the FacesTrace and receive many nice feedbacks from the community. Now the version 0.8.0(beta) is ready and released at sourceforge. In addition to the interesting features mentioned in my previous entry, facestrace now supports logging. We’ve created a custom log4j appender, after configuring log4j.properties(or xml) to use the facestrace appender, you can easily see the logs recorded An example configuration will look like;

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<!DOCTYPE log4j:configuration PUBLIC “-//LOG4J” “log4j.dtd”>
<log4j:configuration xmlns:log4j=”http://jakarta.apache.org/log4j/”>
    <appender name=”FACESTRACE”
        class=”net.sf.facestrace.logging.FacesTraceAppender”>
    </appender>
    <logger name=”your.app”>
        <level value=”DEBUG” />
    </logger>
    <root>
        <level value=”INFO” />
        <appender-ref ref=”FACESTRACE” />
    </root>
</log4j:configuration>

and the result is;

Also we have built the site of facestrace at sourceforge.

Simple Usage of FacesTrace
You need to add the following taglib def. Nevermind if you are using facelets:)
<%@ taglib uri=”http://sourceforge.net/projects/facestrace” prefix=”ft”%>

Place the component at the end of your page’s components.
<ft:trace />

This is all for now, it is time enjoy this interesting fun JSF library.

Rise of the Faces Trace

JSF has no built-in client side validation that is why I’ve created a client side validation library for JSF. Also one of the things missing in JSF is an utility for debugging the flows. With the same state of mind, I’ve realized that it would be cool to create a visual debugger. The lifecycle is well defined and the application developer’s code usually executed at invoke application phase. JSF takes care of the other stuff like conversion,validation and model update.

When something wrong happens I dont think it is tricky to understand the cause of the problem. In order to bring this support to JSF me and my colleague Yigit created an open source project called “Faces Trace”, a library collecting information in a request and presents the whole info using a simple custom component. The usage is as simple as placing <ft:trace /> at the end of the page. Here are some features that we come up with,

* Displaying the execution times of each phase in ms.
* Visualizing the JSF flow using a schema. The phases executed are shown as green, ones that are not are gray, also the phase which caused an error takes the color red.
* Displaying several information in scopes like Application, Session, Request, Params, InitParam and cookies. Using this feature will enable you to see how the application is configured, what is located in session, request, etc and what is posted from the page.
* Since a JSF view is stored in a tree, I thought it would be interesting to map this to a dhtml tree that can be traversable. The dhtml tree contains several information like, id, type and if the component is a value holder, the value information. More info on tree dhtml component tree is here.

Some screenshots showing facestrace in action.

UPDATED: FacesTrace is released at sourceforge, the web site of the project is http://facestrace.sourceforge.net

JSF Chart Creator Example Web Application

Almost every developer hates writing documentations right? I don’t like it either and in my view it must be the techical writers job. It does not change for me whether it is my day job or my open source hobbies, I just hate documenting instead I like to provide sample applications as examples, I did it for acegi-jsf components now it is time for chart creator.

JSF Chart Creator has a forum at jfree.org, referred from several jsf sites like jsftutorials, jsfcentral and myfaces is interested in it.(Damn the license issue by the way). Also I get nice feedback from the community and I guess people with commercial software on jsf charting do not like the free component. These are the good sides about it however frankly speaking the documentation is so bad. I’ve written a poor documentation at sourceforge jsf-comp but it was not enough. That’s why I’ve created a sample web application about how to create several charts using the component. The component supports up to 27 types of charts and I’ve shown almost all of them with different customizations. I’ve released it again at ex-testing ground of myfaces; jsf-comp.

JSF Security Comparison – EL vs Component Approach

After finalizing the release of Acegi-JSF’s new version, I’ve come across to a presentation of Duncan Mills about his JSF Security Project. We’ve already discussed our views with him here, however I really would like to hear your thoughts on this. His presentation contains the following slide that I cannot agree much.

The idea of jsf security project is to provide an EL approach using a variable resolver like;
#{securityScope.remoteUser}
#{securityScope.userInRole['role1,role2,?']}
#{securityScope.userInAllRoles['role1,role2,?']}

Well, I have no problem with the EL approach, actually like it, for example I’ve created a hibernate persistent object lookup resolver that brings all the records in the db when bind to components like combos, listboxes, radio and checkbox groups. Works like this;
#{lookup.classname.key.value.all}

Anyway when comparing these two approaches; EL vs Security Components, these come up to my mind;
1) For example to secure some components on page, one must write the same thing to every single one of the components.

    <h:outputText rendered=”#{securityScope.userInAllRoles['role1,role2,?']}”>
    <h:outputText… rendered=”#{securityScope.userInAllRoles['role1,role2,?']}”>
    <h:outputText… rendered=”#{securityScope.userInAllRoles['role1,role2,?']}”>
    <h:outputText… rendered=”#{securityScope.userInAllRoles['role1,role2,?']}”>
    <h:commandButton… rendered=”#{securityScope.userInAllRoles['role1,role2,?']}”>

Same with component approach;

<acegijsf:authorize ifAllGranted=”role1,role2″>
    <h:outputText…>
    <h:inputText…>
    <h:inputText…>
    <h:outputText…>
    <h:commandButton…>
</acegijsf:authorize>

Imagine a requirement has changed, then you must change it for all the components, component approach provides a more centralized solution. What if a secured component has already a value binding to it’s rendered attribute? EL way brings complexity here.

2) What if there is a need to secure static HTML not just jsf components? The component approach can do it as well.

3) For instance, you have grouped your roles and the role lists are not hardcoded in the jsp but defined in a bean, the component approach allows valuebinding to get the role list from a bean.

<acegijsf:authorize ifNotGranted=”#{yourBeanName.notTheReaderTypeRolesList}”></acegijsf:authorize>

4) Since acegi wraps HttpServletRequest, there is no dependency to acegi or spring. You can use it with a servlet container security as well.(Tested with tomcat).

5) The component approach is likely to secure data-based security. I’ve not implemented this one but surrounding a jsf datatable with an acegijsf component will filter the list of the datatable and allow only the records that the given user can see.(ACL).

6) Finally and my favorite, the component way provides an abstraction between the ui components used for business and the security context of the application. The secured components do not know their position in the security context and do not depend on anything. This brings flexibility, maintainability and decoupling. Wait! aren’t those some of the principals of good software design?

Above are the advantages of the component way I can think of at first glance. Acegi project team also favor this way and informed the users about acegi-jsf components at their home sourceforge site.(http://acegisecurity.org/articles.html).

So, as I mentioned, I am wondering about your thoughts on the comparison, what do you think about these approaches to the JSF Security, any more pros and cons?

New release of ACEGI-JSF Components

Last night, the maintenance of cvs service at sourceforge is finished and I finally got the chance to release the new version of acegi-jsf components. The version is 1.1.2 which is a mainly bug fix actually. In our project, we’re using the new version for some time and no problem so far.

•  The group rendering algorithm was subject to fail in some cases, fixed in this version
•  The whitespace problem in the given role list is fixed.
•  Support to secure the static html is provided in this version.
•  A state saving bug in 1.1.1. is fixed
•  A sample web application demonstrating the integration of jsf-spring-acegi
  and usage of the component library is also released.

I’ve also updated my entry on the component library which is used as a getting started documentation.