Large Scale JSF Projects Revisited

Posted by Dominik Thu, 04 Oct 2007 10:20:00 GMT

Seven months ago I asked the question Who has done large scale JSF projects?. Now Alain O’Dea took the time to answer those questions and shares his experience with a large JSF project. Since his comment provides very useful and interesting information, I thought I do a fresh post that links directly to his comment:

Alain O’Dea on his large scale JSF project

Posted in  | Tags ,  | no comments | no trackbacks

Chiming in: JSP - Innocence Lost

Posted by Dominik Fri, 15 Jun 2007 13:36:00 GMT

Yesterday Angsuman Chakraborty wrote about his feelings concering JSP.

I totally agree with him. 7 to 8 years ago I was on several projects which used JSP. These projects ranged from one month with 2 developers to 1 year with 10+ developers. And they actually were fun to do.

Starting this year I was (and still am) involved in two projects which again used Java technology for the web frontend.

The first was using JSF. No real support for POST says all.

The current project is using plain JSP with Spring. I admit that Spring is a lot easier than EJB 2.1, but for me it still goes tha Java framework way of making difficult things possible but at the same time making easy, “default” behavior difficult.

Expression Language is something which was introduced to Java web development which I wouldn’t want to miss. But the whole setup of a JSP project using the current stack is, imho, too difficult. When Angsuman says that the current JSP technology is not usable for rapid prototyping he is right. I guess it will take most programmers between two days to a week to set up the infrastructure and build support for an JSP project.

OK, if you use tools for RAD, you might be faster, but I always like to know what is getting generated, just in case that it might not work as it should (which will happen, that is sure).

When the customer is not forcing me to use java for a web application, I would never use it. But then I guess I really have already departed.

Posted in ,  | Tags , ,  | no comments | no trackbacks

Who has done large scale JSF projects?

Posted by Dominik Mon, 12 Mar 2007 16:30:00 GMT

Whether successful or not, have you been involved in large scale JSF projects?

If yes, can you share some project statistics with the blogosphere and me in particular?

  • The number of managed beans?
  • The number of views?
  • The number of custom components?
  • The load on the server(s)? How many concurrent users?
  • Which JSF implementation did you use?
  • Did you use RAD tools?
  • What where your pain points?
  • What do you think is JSF’s sweetspot?
  • Have you had concerns with bookmarkability?
  • Would you write your next web-application using JSF and, if not, why not?
  • Can you give a short description about the project?

I have been looking around for descriptions of real world JSF projects on the web but haven’t found many articles, so if you feel you can answer some of the questions above, please leave a comment or a trackback.

P. S.: If I have missed the definitive resource on projects done with JSF in my search, please tell me so.

Posted in  | Tags  | 5 comments | 12 trackbacks

My thoughts about "JSF is way too complicated?"

Posted by Dominik Sun, 18 Feb 2007 12:16:00 GMT

Imho, JSF is not too complicated. JSF was conceived for specific goals, and I think that JSF matches these goals very well. When you want to develop a java web application and can follow the path that JSF has laid out for you, you are well served. Integration with IDEs is available, RAD support, drag and drop development, it’s all included in the package. So, yes, JSF is not too complicated, if you use it the way it should be used.

JSF, e. g. , abstracts away the low level request-response layer inherent in all applications delivered over HTTP. I agree with Tim Shadel that the abstraction is leaky, but maybe programmers new to web development have something to gain from this abstraction.

It is only when you leave the troten path, when you make design decisions that were not considered in JSF, that JSF gets complicated. And even then, it is not actually JSF that gets complicated, but the fact that you have to work around a framework which was supposed to help you. It gets complicated because you have to dig through the seven layer burrito down to the request and the response to do what you want to do. Managed beans in request scope and bookmarkable URLs are, in my experience, things that have either not been considered in JSF, have been omitted on purpose or were, to the JSF creators, on the fringe of things considered necessary for a web framework.

I have done web development in Java since about eight years, starting out with Servlets going over JSP to JSF. I have also done web development in Perl, PHP and Python. And I currently do all my off-work projects in rails. Having worked with different frameworks written in different languages, I feel like there is a sweetspot between abstraction and allowing easy access to low level HTTP. And that sweetspot surely isn’t universal. But it seems that I share the same sweetspot with a lot of programmers. For me it’s rails. BUT: that does not mean that I would say that JSF is bad! It is just not a the level of abstraction I would like to work at.

Posted in  | Tags , ,  | no comments | no trackbacks

JSF: DataTable and CommandLink

Posted by Dominik Wed, 07 Feb 2007 13:39:00 GMT

Like a lot of other programmers who are forced to work with JSF, I fell into THE TRAP!

If you are using ManagedBeans in request scope, you get problems with CommandLinks inside DataTables.

DataTables are one thing I really like about JSF, and CommandLinks often come in handy as well. But when you put a CommandLink inside a DataTable, e. g., to select the entry of the row in which the CommandLink is, you get bitten. That is, if you want ManagedBeans with request scope. The action which should be triggered by the CommandLink is never triggered, the page is simply rendered again.

The reason for this behaviour is that the DataTable modifies the id of the CommandLink during renderering, but the CommandLink does not know that it was rendererd with a different id. During the decoding of the request which was triggered by clicking the CommandLink, the ComandLinkRenderer looks at a hidden form parameter. If the value of that form parameter equals the id of the CommandLink, an action is queued. If not, nothing is done.

Since the DataTable changes the ids, the value of the hidden form parameter does not match the id of the CommandLink.

So I wrote my own CommandLinkRenderer, overwrote the decode method and patched it so that the id match up again. When I want a CommandLink in a DataTable, I then specify that it should use my CommandLinkRenderer.

Here is the source of the decode method:


     @Override
    public void decode(FacesContext context, UIComponent component)
    {
        if (context == null || component == null)
        {
            throw new NullPointerException(Util
                    .getExceptionMessageString(Util.NULL_PARAMETERS_ERROR_MESSAGE_ID));
        }

        if (log.isTraceEnabled())
        {
            log.trace("Begin decoding component " + component.getId());
        }

        UICommand command = (UICommand) component;

        // If the component is disabled, do not change the value of the
        // component, since its state cannot be changed.
        if (Util.componentIsDisabledOnReadonly(component))
        {
            if (log.isTraceEnabled())
            {
                log.trace("No decoding necessary since the component "
                        + component.getId() + " is disabled");
            }
            return;
        }

        String clientId = command.getClientId(context), paramName = getHiddenFieldName(
                context, command);
        Map requestParameterMap = context.getExternalContext()
                .getRequestParameterMap();
        String value = (String) requestParameterMap.get(paramName);
        clientId = clientId.substring(0, clientId.lastIndexOf(":"));
        value = value.substring(0, value.lastIndexOf(":"));
        if (value == null || value.equals("") || !clientId.equals(value))
        {
            return;
        }
        ActionEvent actionEvent = new ActionEvent(component);
        component.queueEvent(actionEvent);

        if (log.isDebugEnabled())
        {
            log.debug("This command resulted in form submission "
                    + " ActionEvent queued " + actionEvent);
        }
        if (log.isTraceEnabled())
        {
            log.trace("End decoding component " + component.getId());
        }
        return;
    }

The diff to the original method is:


diff CommandLinkRenderer.java PatchedCommandLinkRenderer.java
124a125,126
>       clientId = clientId.substring(0, clientId.lastIndexOf(":"));
>       value = value.substring(0, value.lastIndexOf(":"));

It works form me, maybe others get some benefit from it as well.

(P.S. this is crossposted to http://forum.java.sun.com/thread.jspa?threadID=5116147)

Posted in  | Tags  | 17 comments | no trackbacks

How to make JSF navigation rules more dynamic

Posted by Dominik Wed, 24 Jan 2007 13:22:00 GMT

Consider the following situation:

You do a post request from some form in an JSF application and want to decide on the page to redirect to dynamically. No problem, just use different “navigation-case” entries and go to different “to-view-id”s depending on the “from-outcome”.

<navigation-rule>
    <from-view-id>/pages/organisation/*</from-view-id>
    <navigation-case>
        <from-action>#{OrganisationBean.select}</from-action>
        <from-outcome>to-user</from-outcome>
        <to-view-id>/pages/user/details.jsf</to-view-id>
        <redirect/>
    </navigation-case>
    <navigation-case>
        <from-action>#{OrganisationBean.select}</from-action>
        <from-outcome>to-project</from-outcome>
        <to-view-id>/pages/project/details.jsf</to-view-id>
        <redirect/>
    </navigation-case>
    <navigation-case>
        <from-action>#{OrganisationBean.select}</from-action>
        <from-outcome>to-whatever</from-outcome>
        <to-view-id>/pages/whatever/details.jsf</to-view-id>
        <redirect/>
    </navigation-case>
</navigation-rule>

Sure, this works. It’s not exactly what I would call DRY, but it works. But what if you need to be more dynamic then that?

Just use a framework that’s more dynamic I hear you say.

Sure, I’d love to. But what if that is not an option?

I found this, this and this on the web, and putting these together gave me the following solution which I wanted to share with you:

Step 1:

Create a ViewHandler, in my case a subclass of com.sun.facelets.FaceletViewHandler and overwrite getActionURL():

@Override
public String getActionURL(FacesContext context, String viewId)
{
    String result = viewId;
    if(Util.isVBExpression(viewId))
    {
        ValueBinding vb = context.getApplication().createValueBinding(viewId);
        result = vb.getValue(context).toString();
    }
        result = super.getActionURL(context, value);
    int queryStart = value.indexOf("?");
    if((queryStart > 0) && (result.indexOf("?") == -1))
    {
        result = result + value.substring(queryStart);
    }
    return result;
}

This enables you to use EL in the to-view-id entry of a navigation case.

Step 2:

Register your view handler with the application, in my case:

<application>
    ...
    <view-handler>com.interactive_objects.jsf.crud.generic.DynamicViewHandler</view-handler>
</application>

Step 3:

Now you can do things like:

<navigation-rule>
    <from-view-id>/pages/organisation/*</from-view-id>
    <navigation-case>
        <from-action>#{OrganisationBean.select}</from-action>
        <from-outcome>selected</from-outcome>
        <to-view-id>#{OrgansiationBean.computedRedirect}</to-view-id>
        <redirect/>
    </navigation-case>
</navigation-rule>

(You can also use compound expressions like “/path/to/page.jsf?foo=#{ManagedBean.bar}”).

Tags ,  | 8 comments | 3 trackbacks

More fun with JSF

Posted by Dominik Tue, 23 Jan 2007 17:54:00 GMT

I’m getting into the flow of JSF at last. OK, flow might be too big a word, maybe it’s more like walk or stumble, but I’m diverting.

My official work these last days has been the creation of a generic component for CRUD operations in JSF, something that is fed with an interface or an class, configured and which then provides views for CRUD operations, lists and Searching and a controller which delegates the work of providing the right instances to a middle tier.

Such a component comes in handy when you have a huge domain model and need CRUD functionality for all domain classes. Sure, it is possible to generate the backing beans and views, but as long as the domain model is still a moving target, you need to regenerate those beans and classes each time a property or association is added to or removed from one of the domain classes. The company I’m working at has profound knowledge of everything that has to do with generation, but we also know that there are situations in which you can simply overdo things (the old problem that to someone who owns (only) a hammer, everything is a nail).

So we decided on a component which does the heavy lifting in this case. We will (most likely) still generate the classes needed to configure the crud component for the different domain classes, but after that we are not forced to touch the views or the backing bean when the domain class changes.

Maybe I’ll come back to write some more about this later on.

Tags , ,  | no comments | no trackbacks

Page URLs in JSF Applications revisited

Posted by Dominik Mon, 08 Jan 2007 17:55:00 GMT

Since I have to work with JSF (the customer wants it badly) I spend some time digging for ways to make the URLs of JSF Pages less annoying. I’ve found valuable information from Gavin King via http://www.theserverside.com/news/thread.tss?thread_id=38601 on how to use GET for JSF. I even went as far as to try my hands on something similar to rails’ routes. It works alright so far, but I still find it strange that there is now easy Out-Of-The-Box way to do GET requests in JSF. Have I simply missed something? I wouldn’t want to miss the value binding and some of the JSF components make writing Java webapps a better experience. All the declarative parts are fun to use. But it’s way too much xml. I’d rather specify which view to show after an action somewhere near the action, if possible in Java code, and not in some xml file. Right now I’ve got the feeling that the creation of a JSF webapp with URLs that are at least bookmarkable forces me to work my way around JSF’s core, and that seems like a stupid thing to do, when I use a framework.

Or maybe simply I shouldn’t have read this here.

Posted in  | Tags  | no comments | no trackbacks

Page URLs in JSF Applications

Posted by Dominik Fri, 05 Jan 2007 15:51:00 GMT

Is it just me, or is the following behavior annoying others as well?

I’ve been playing around with JSF lately and noticed that the URLs displayed by the browser and the pages shown don’t match.

The minimal setup I used was a page which lists all users and a page which displays the details for an user named, respectively, users/list.jsf and users/details.jsf.

The navigation part of the xml configuration I’m forced to write for that trivial application looks like:

    <navigation-rule>
      <from-page-id>/users/list.jsf</from-page-id>
      <navigation-case>
        <from-outcome>success</from-outcome>
        <to-view-id>/users/details.jsf</to-view-id>
      </navigation-case>      
    </navigation-rule>
    <navigation-rule>
      <from-page-id>/users/details.jsf</from-page-id>
      <navigation-case>
        <from-outcome>success</from-outcome>
        <to-view-id>/users/list.jsf</to-view-id>
      </navigation-case>      
    </navigation-rule>

When I navigate to /users/list.jsf the list page is shown as expected. Once I select an entry I get served the details page. Sounds OK, but the browser is still showing /users/list.jsf as URL. And when I use a link on the details page to go back to the list page, the list page gets displayed again. That is fine as well. But now the browser shows /users/details.jsf as URL.

I’ve tested this with not only list and details, but the whole bunch of CRUD pages for Users, and the behavior is consistent. Consistently wrong.

Am I missing a point here?

Somehow I’m used to having some kind of relation between the URL shown by the browser and the page displayed. As I’m typing this, e. g., the URL shown is typo/admin/content/new and not typo/admin/content (which would have been the overview page). Now I have written and used my part of Java web applications, and often the URL shown by the browser was totally useless, but even that is an better behavior than having the wrong URL shown to you.

And it seems like I’m not doing everything wrong. Just checkout the URLs shown in Figures 4 & 5 of http://www-128.ibm.com/developerworks/java/library/j-jsf2/index.html. The same behavior over again.

And I haven’t even started to talk about the fact that, even if the right URL were shown for the details page, I could not bookmark it, because it carries no information about the user whose details I’m viewing at the moment.

Seems like I’m already spoiled by rails…

Posted in  | Tags , ,  | 2 comments | no trackbacks