• download PagedList

Lazy loading with the PagedList

Originally I made the PagedList because I needed paged data fetching using JMS queues for a JSF Rich datatable and datascroller; a common problem in JSF but less commonly solved, even less documented and less still solved in an elegant way. Most people are able to solve this problem by using an OpenSessionInView antipattern (keeping Hibernate-oid session open until the view requests the lazy loaded data) but since I’m using JMS queue, this was not an option. I decided to circumvent the entire JSF to JMS queue integration by providing my data in a paging lazy list. It works beautifully.

public class PagedList<Dto, QueryParameters> extends AbstractList<Dto> {

    private final QueryParameters queryParameters;

    private final PagedDataProvider<Dto, QueryParameters> pagedDataProvider;

    private final Map<Integer, List<Dto>> fetchedPages;

    private final int dataSize;

    private final int pageSize;

    public PagedList(PagedDataProvider<Dto, QueryParameters> pagedDataProvider, QueryParameters queryParameters) {
        this.pagedDataProvider = pagedDataProvider;
        this.queryParameters = queryParameters;
        fetchedPages = new HashMap<Integer, List<Dto>>();
        dataSize = pagedDataProvider.getDataSize();
        pageSize = pagedDataProvider.getPageSize();
    }

    public Dto get(int index) {
        int pageNr = (int) Math.floor(index / pageSize);
        if (fetchedPages.get(pageNr) == null) {
            fetchedPages.put(pageNr, pagedDataProvider.provide(pageNr, queryParameters));
        }
        return fetchedPages.get(pageNr).get(index % pageSize);
    }

    public int size() {
        return dataSize;
    }
}

It is different from Apache’s LazyList (and many other implementations) in that it relies on an external dataprovider to provide the dataset’s total size, pagesize and data provision itself. For example, using my lazy list version the size() method actually returns the total size of data potentially available, not just physically available in the list at the present. This way the list works completely transparent to its users. Also, there is no simple factory being passed in that creates dummy objects or something: actual remote data is being fecthed in pages by a data provider. Pages being fetched are independent of each other; when requesting page 5, page 1 through 4 are not need or fetched.

The PagedList works in combo with a PagedDataProvider interface that external dataproviders (some dao for example) could implement. So it has no dependencies whatsoever on some specific implementation. The paged data provider provides the total size of the dataset, the page size and pages of the dataset itself when needed.

Example implementation for JSF and JPA dao

Here’s an example implementation which ties a JSF Richfaces datatable to a JPA dao using a PagedList. I cut out the service layer, view handlers/controllers and whatnot for sake of simplicity.

<rich:dataTable id="searchResults" value="#{appleService.apples}" var="apple">
...
</rich:dataTable>

/**
 * JPA dao which acts as paged data provider for the paged list.
 *
 * Relies on two JPA named queries specified on the Entity being fetched.
 *
 * @author Benny Bottema
 * @see PagedDataProvider
 */
public class AppleJPADao implements AppleDao, PagedDataProvider<AppleDto, AppleQueryParameters> {

    // entitymanager stuff omitted for example (real world: injected by Spring)

    private static final int PAGESIZE = 50;

    /**
     * @see AppleDao#getAllApples(String, String)
     */
    public List<AppleDto> getAllApples(String type, String quality) {
        // optional query parameters: can be null
        AppleQueryParameters params = new AppleQueryParameters();
        params.setAppleType(type);
        params.setAppleQuality(quality);
        return new PagedList<AppleDto, AppleQueryParameters>(this, params);
    }

    /**
     * @see PagedDataProvider#provide(int, Object)
     */
    public List<AppleDto> provide(int page, AppleQueryParameters queryCriteria) {
        Query query = entityManager.createNamedQuery("Apple.findAll");
        query.setParameter("appleType", queryCriteria.getAppleType());
        query.setParameter("appleQuality", queryCriteria.getAppleQuality());
        // JPA's paging mechanism
        query.setFirstResult(PAGESIZE * page);
        query.setMaxResults(PAGESIZE);
        return (List<AppleDto>) query.getResultList();
    }

    /**
     * @see PagedDataProvider#getDataSize()
     */
    public int getDataSize() {
        Query countQuery = entityManager.createNamedQuery("Apple.count");
        return ((Long) countQuery.getSingleResult()).intValue();
    }

    /**
     * @see PagedDataProvider#provide()
     */
    public int getPageSize() {
        return PAGESIZE;
    }
}

Known issues

So far there is only one known issue, which is more of a problem with lazy loading in general: synchronizing the lazy loading list with the remote dataset to avoid becoming stale when changes happen to the dataset. Example: when the dataset changes, the size of the list is not being updated and the get() method may try to fetch wrong or even unavailable data throwing an exception. Since I’m using the paged list in a limited way, I’ve not yet encountered this problem.

One way would be to solve this problem for the Rich datable and datascroller specifically is to have a a4j poll component that listens for dataset changes on the server and refreshes the entire datatable as necessary. Just thinking out loud here…

trackback

[RE: JSF – Still pretty much a steaming pile of donkey turd] – I was replying to Wille Faler’s post about why JSF sucks, when the comment was getting too large, so I made it into a post on my own blog.

JSF is hard to learn yes, but in my opinion it doesn’t suck as bad as Wille says. All the points Wille mentions can be solved by certain libraries or write-once reusable solutions (I’ve included my ‘magical’ combination of frameworks on the bottom). JSF is a diamond in the rough, you just need to make it shine.

The devil is in the details

There are a couple of pitfalls you need to know about with JSF. It’s all really a matter of having read a good book about JSF that points them out, or having learned them the hard way. Luckily I’ve had some guidance by experienced colleagues of mine; I’m guessing that’s the missing factor in Wille’s situation.

Referring to the pitfalls you need to know about, I’m talking about the common beginner’s problems like using JSTL c:tags that cause havoc when combined with those of jsf and facelets. I’m talking about the Ajax4Jsf details as Wille mentioned: once you know what to use it’s easy. Those 48 attributes? most of them are inherited and never used and you can forget about them, and that’s the learning curve. Once you know the right ones, it’s using exactly those, over and over again. And things like how you can incorporate Spring security and stuff like that. Another pitfall that comes to mind is how action=”" work quirky with navigation rules when using the array notation (action=”controller['action']“). And ofcourse there’s the issue of parameterized JSF validators, which needs some understanding. All pitfalls that can baffle a beginner or intermediate.

The thing with JSF is there are a number of little things that are hard to solve, but once you’re past that it does make you much more productive. You just have to have a solid base to start from each project. The pitfalls learning curve is definitely a downside of JSF, but JSF 2.0 is in the making to solve all these issues.

Bad performance or beginner’s mistake?

Then there is this performance issue Wille mentions, where I think he missed the target: JSF does not have to be slow at all. It really depends on how you treat your backing beans. JSF has the weird tendency to call setters/getters multiple times, which seems utterly pointless (it’s related to resolving valuebindings in nested components). I’ve made the mistake before to directly retrieve values from a controller/service in my views instead of a static model (backing bean): this is what makes things slow. JSF in itself isn’t that slow for a webapp: yes there are many redundant calls but we’re not dealing with a realtime simulation application, webapps do just fine. On a sidenote, it also depends on the implementation… JSF is a reference specification, while there are various implementations of the framework (IBM’s, Sun’s etc.)

SEO friendly JSF?

Ahh, but for the JSF Search Engine Friendliness. That’s solved too, somewhat. There’s is a framework called PrettyFaces which allows you to dynamically generate/interpret pretty GET urls with bean values. It’s a great framework that solves a common problem, but there still exists the problem that existing jsf/facelets/richfaces components are not generating SEO HTML code. That’s really the fault of the component makers, not JSF, though JSF definitely isn’t innocent with its POST obsession: PrettyFaces fixes at least that.

Common sense: use frameworks to avoid most pitfalls

Once you’ve got those kind of things down and use a good framework combo, JSF is straightforward. You won’t really need to know about the various phases and you can be very productive if you’ve set up the jsf/facelets components right. I’ve worked with JSF intensively for about a year now in various projects with various implementations and I hardly ever need to use phaselisteners and that sort of stuff. The rare cases where you do need them, you can define these things ones and reuse them in other projects. With this approach I’ve created a template project with some standard libraries, phaselisteners, security set up, facelets components etc. and I’m up and running in no time.

I haven’t sanitized or otherwise cleaned up the template project so I won’t put that up for the time being, but at least I can tell you what frameworks are in it by default.

The magical combination that works for me and my colleagues:
• JSF (MVC)
• Facelets (Templating, use of XHTML)
• Richfaces (component suite)
• Richfaces A4J (Ajax support)
• Tomahawk (only for file uploads with the Extensions Filter)
• PrettyFaces (for indexable GET urls)

Now that I’ve mentioned these, you should check out JBoss Seam as well, which basically is supposed to do everything the above libraries do combined, plus a couple of things more like solving the conversational scope issue. I haven’t worked with this framework myself though so I can’t speak from experience.

Final note

Although I agree JSF has some annoying pitfalls, shortcomings and a high learning curve, it’s been out there for enough time to pass for supplement frameworks to pop up from under the ground to solve most of these problems.

With the right combination, most classic counter arguments have become obsolete. Maybe it’s time for critics to take JSF as is: incomplete but ultimately making you more productive if combined with the right frameworks.

trackback