Mark McLaren's Weblog

AJAX decoration: using jQuery Metadata for portlet AJAX

Tue, 09 Mar 2010 14:14:25 GMT

I recently examined a JSR 168 portlet which tackled the thorny area of AJAX in a Portlet ( incidentally the portlet I was looking at is the Jasig Calendar Portlet ). The technique used makes all AJAX requests into POSTs which are then passed via the portal and a redirect to a servlet to acquire the desired response. I am not new to JSR 168 portlets and have personally produced several portlets over the past few years. I have also solved the AJAX in a Portlet problem but in a completely different way. The solution I developed I am calling AJAX decoration and relies on the jQuery Metadata plugin. I think both techniques have their merits and possibly could be applicable to different scenarios. I will attempt to illustrate my solution with a simple example app (note this example is not an actual portlet and will work in your servlet container of choice).

The structure of each of my "portlet" JSPs in my example is something like this:

header.jsp

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<script type="text/javascript" src="jquery-1.3.2.min.js"><!-- --></script>
<script type="text/javascript" src="jquery.metadata.js"><!-- --></script>
</head>
<body>
<div id="content-area">

footer.jsp

</div>
<script type="text/javascript">
    var pageContext = "${pageContext.request.contextPath}";
    var targetArea = "div#content-area";
</script>
<script type="text/javascript" src="ajaxDecorated.js"><!-- --></script>
</body>
</html>

somepage.jsp

<%@ include file="header.jsp" %>
<h1>Some Page</h1>

<!-- Content goes here -->

<%@ include file="footer.jsp" %>

Notice that we will be using a consistent target area for our AJAX loaded content; in this case a div with the ID of "content-area". The jQuery Metadata plugin makes it possible to read data stored within CSS classes, doing this is a relatively clean way of storing data within our page. In this approach the content links are decorated with data and in turn this data is used to assign appropriate AJAX behaviour.

For a typical link using a GET we could use:

<a href="page1.jsp" class="ajaxRenderURL {link: '/page1.jsp'}">page 1</a>

For form submission we could use:

<form action="page2.jsp" class="ajaxActionURL {link: '/page2.jsp'}">
    <input type="submit" />
</form>

The magic happens in the "ajaxDecorated.js" file. When the page initially loads initPage() is invoked which attaches AJAX loading behaviour to links and forms.

$(document).ready(function() {
    initPage();
});

function setupLinks(){
    var data = $(this).metadata();
    var loadlink;
    var tsSeparator = "&";
    if(data.link.indexOf("?") == -1){
        tsSeparator = "?"
    }
    if(!data.link.match("^" + pageContext)){
        loadlink = pageContext + data.link + tsSeparator + new Date().getTime() + " " + targetArea;
    } else {
        loadlink = data.link + tsSeparator + new Date().getTime() + " " + targetArea;
    }
    $(targetArea).load(loadlink, null,
        function () {
            initPage();
    });
    return false;
}

function setupForms(){
    var data = $(this).metadata();
    var formdata = $(this).serializeArray();
    var loadlink;
    if(!data.link.match("^" + pageContext)){
        loadlink = pageContext + data.link + " " + targetArea;
    } else {
        loadlink = data.link + " " + targetArea;
    }
    $(targetArea).load(loadlink, formdata,
        function(){
            initPage();
    });
    return false;
}

function initPage(){
    $(targetArea).find('a.ajaxRenderURL').click(setupLinks);
    $(targetArea).find('form.ajaxActionURL').submit(setupForms);
}

This technique adds AJAX to a web page in an unobtrusive way. In this simple example the URLs loaded by AJAX and those that would be loaded without are the same (page1.jsp, index.jsp etc). However, in an environment where the AJAX URLs and web page URLs are likely to be different or even change dynamically (such as in a portal) then this technique is equally applicable.

DisplayTag: Producing Decorators for Lists of Maps

Thu, 25 Feb 2010 11:33:35 GMT

I have been using the Display tag library (hereafter referred to as displaytag) heavily on a big in-house web application project. Displaytag helped me make relatively short work of pagination and data export, the resulting pages look very professional to boot. Best of all using displaytag meant I was able to concentrate my efforts on other parts of the project.

Much of the time I use the displaytag in the typical way (e.g. to display collections of beans). However, the changeable nature of some of the reports required lead me to produce some of the screens using Lists of Maps. Lists of Maps are very easily acquired from a database (e.g. Spring's ColumnMapRowMapper). Once you configure displaytag to display lists of maps then you have the flexibility to make changes to the report contents purely by changing an SQL statement. Also using the SQL "AS" keywords means that user friendly table column names are easily supported. So by making use of lists of maps you can produce very flexible and easily extensible reporting screens.

So far, so good...

Formatting data and adding extra display columns

By default whether you are passing a collection of beans or a list of maps to displaytag it just works! e.g.

<display:table name="dummyData"></display:table>

Elsewhere where I have used the typical way (collections of beans) of supplying data to displaytag. Sometimes I need to reformat a date, currency column or change some columns into links. You can do most of this inside the JSP page (messy!) or alternatively you can make use of the displaytag TableDecorator. You can also use TableDecorator's to add new columns that don't exist in the data, however, once you start specifying custom generated columns then you need to explicitly specify all the columns you would like to see in the displaytag table, e.g.:

<display:table name="dummyData" decorator="edu.bristol.SampleDecorator">
     <display:column property="id" />
     <display:column property="date" />
     <display:column property="url" />
     <display:column property="columnPopulatedByTableDecorator" title="Decorator generated"/>
</display:table>

I wanted to do this with a list of maps. After a little research on the forums, I found that you could still make use of TableDecorator generated custom columns by explicitly specifying the columns in your map. As the data originates from the database, each list row will contain a map with the same set of map keys. First you retrieve the map keyset from the first result row, store this keyset in the request and then you can explicitly iterate through the map columns:

<display:table name="dummyData" decorator="edu.bristol.SampleDecorator">
       <c:forEach items="${keyset}" var="key">
             <display:column property="${key}" />
       </c:forEach>
     <display:column property="columnPopulatedByTableDecorator" title="Decorator generated"/>
</display:table>

At this point, the "columnPopulatedByTableDecorator" will be generated but the TableDecorator doesn't do any re-formatting of the existing data columns.

Producing Decorators for Lists of Maps

So now we come to the novel aspect of this blog entry! The next question is how I reformat the data in my list of maps for displaytag purposes. I searched through the forums and couldn't get an answer for this, so I came up with a solution. Internally, displaytag uses Commons BeanUtils for data manipulation. We have seen that it can handle lists of maps without any additional configuration - so it must be doing something clever! The TableDecorator test code for displaytag includes tests for accessing mapped data, so I knew that it should be possible to access the mapped data in my own TableDecorator. Part of the difficulty in accessing the data is that my key names were not easily transformed into Java method names, the keys contain spaces, capitalization and other characters that are not permitted in a method name. My solution was to alter my list of maps to become a list of "wrapped maps". Where a wrapped map looks something like:

public class WrappedMap {

    Map m;

    public WrappedMap(Map m) {
        this.m = m;
    }

    public Object getMap(String propertyName) {
        return m.get(propertyName);
    }
}

My decorator for this list of wrapped maps could now access my oddly named keys, such as:

public class WrappedMapDecorator extends TableDecorator{

    final private String startDate = "Start Date";
    final private String websiteAddress = "Website Address";

    public String getMap(String propertyName){
        WrappedMap wm = (WrappedMap) getCurrentRowObject();
        Object propertyValue = wm.getMap(propertyName);
        if(startDate.equals(propertyName)){
            // Implement appropriate formatting/decoration
            return "<i>" + propertyValue.toString() + "</i>";
        }
        if(websiteAddress.equals(propertyName)){
            // Implement appropriate formatting/decoration
            return "<b>" + propertyValue.toString() + "</b>";
        }
        return propertyValue.toString();
    }

}

Finally, my JSP would need to be tweaked to produce the appropriate table:

<display:table name="dummyData" decorator="edu.bristol.WrappedMapDecorator">
    <c:forEach items="${keyset}" var="key">
           <display:column property="map(${key})" title="${key}" />
    </c:forEach>
    <display:column property="columnPopulatedByTableDecorator" title="Decorator generated" />
</display:table>

I am happy with this solution. I maintain the flexibility that the List of Maps technique makes possible but it is also possible to decorate the supplied data.

Incidentally, you may have noticed that I haven't been blogging much in recent times. I am now the father of 2 pre-schoolers and so what free time I get is usually spent collapsed in a heap rather than blogging! Anyway I hope you find this useful...

Spring Web Flow 2 Web Development: Book Review

Fri, 21 Aug 2009 21:49:49 GMT

I have been keeping the good people of PACKT Publishing waiting some time for this short review; they were kind and prompt in sending me their book - in my defence I have been very busy lately. I had hoped to include some example code but as I am still short on time right now I thought I would release a general review first and maybe something with some example code at a later date when I've had some more time to digest the book further. To business, Spring Web Flow 2 Web Development is a book for Spring developers who want to give Spring Web Flow a try. So what is Spring Web Flow? As described in following excerpts from the book (page 9):

"...- you can use Spring Web Flow to create conversational web applications. ...For example, take an application with a wizard-like interface. ...You are working in a predefined flow with a specific goal, such as ordering a book or creating a new user account. ...Spring Web Flow makes it very easy to create flows. Flows created by Spring Web Flow are not only decoupled from the applications logic, but are also re-usable in different applications. A flow in Spring Web Flow is a sequence of steps, that is, with states and transitions between them. There are also actions that can be executed on various points, for example, when the flow starts or the web page is rendered..."

This book is intended to describe Spring Web Flow 2 and any book which ties itself to a particular version is going to date quickly but that said you are bound to learn something new reading this book.

The book contains the obligatory chapters describing the Spring Web Flow 2 concepts and exploring what has changed since the last version, the distribution and example code. It also has a chapter on setting up your development environment be that Ant, Maven, Eclipse (and Spring IDE) or NetBeans. A chapter on JavaServerFaces integration using the Spring Web Flow 2 "Spring Faces" module, as I've never properly explored JavaServerFaces I'm not qualified to comment on this. The sample project that is used throughout the book is a simple bug tracking system ("flow.trac"). With this project there is plenty of scope to explore what Spring Web Flow 2 has to offer in terms of user interface (JavaScript including AJAX, Apache Tiles etc.), testing (JUnit and EasyMock) and security (Spring Security) whilst utilising a JPA (Hibernate) database layer. In the appendix it shows you how you can run your code on the SpringSource dm Server and gives a gentle introduction to making you application work in an OSGi environment. The source code for the book is available @ www.packtpub.com/files/code/5425_Code.zip

One of my early impressions was one of surprise, I admit to raising an eyebrow that they chose to use Microsoft SQL Server 2008 Express Edition as their example database server. I would expect something more lightweight such as H2 or Apache Derby -e.g. something you could easily bundle as part of a Maven build.

The intended audience for this book seems to be people who plan to use the triumvirate of Spring, Spring MVC and Spring Web Flow. From my perspective Spring is a gimme and you are obviously interested in Spring Web Flow (that is why you bought the book!) but I'm not so sure you are always free to choose Spring MVC. To be fair the book goes to great pains to say that Spring Web Flow can be used with other technologies but as my main web development MVC framework is still good ole' Struts 1.3, it would be nice to see some examples of using Spring Web Flow 2 with something other than Spring MVC or maybe even in a more exotic environment like inside a Spring MVC portlet. Spring Web Flow 2 includes components for integrating with JavaScript. I have to admit to being a jQuery devotee so any alternate JavaScript technology seems a bit unnecessary to me but I can see it could be useful to some folks.

All in all and so far, I have found reading this book to be very enjoyable. It is nice to see how other developers go about things, I found myself reading and thinking "I wouldn't do it that way" AND "That's clever, I'd never have thought of that!". The experience of reading this book is very much like shadowing some very experienced senior Java developers.

Coming soon: Spring Web Flow 2 Web Development: Book Review

Tue, 11 Aug 2009 13:19:19 GMT

PACKT Publishing very kindly sent me a copy of Spring Web Flow 2 Web Development to review. I have been very busy with work so I have not yet gotten around to reviewing it but I plan to publish something in the not too distant future. So watch this space!

jQuery UI ThemeRollerReady IFRAME in a dialog box

Thu, 02 Jul 2009 21:47:06 GMT

Whilst making preparations for upgrading to uPortal 3.1.x from uPortal 2.5.x I came into contact with jQuery UI themes.

In our previous portal the help screens were displayed using Cody Lindley's ThickBox. At the time I first introduced Thickbox to our portal I thought this was pretty revolutionary, clicking on a link made the background dim and the help text (via an IFRAME) was shown in sharp contrast in the foreground of the page (very Web 2.0!).

The interface for uPortal 3.1 has evolved considerably from 2.5.x. The fluid project have worked on uPortal 3.1 to improve the user experience. jQuery and jQuery UI have become an integral part of the uPortal interface. uPortal 3.1 makes good use of jQuery UI dialog and tab widgets. (Incidentally, when did dialogue become dialog?) As the range of jQuery UI widgetry expands so too will the options for portal improvement, all with a common look and feel and easily themed.

In our new portal I would still like to access the help pages in a Thickbox/IFRAME style. However, the jQuery plugins that provide this kind of functionality (Thickbox and jqModal) do not look like the other jQuery UI widgets and are not themeable via jQuery UI themes. I could probably map the plugin CSS to the jQuery UI theme CSS but this seems like it could be a lot of work. So I have produced my own version of a dialog using an IFRAME.

I am fairly new to jQuery and what I have produced isn't quite up to jQuery plugin standard but if somebody out there wanted to apply some finishes touches to it I would be happy to contribute it back to the jQuery effort. The main difference between my effort and Thickbox and jqModal is that I am only interested in IFRAMEs and my version should be ThemeRollerReady. All being well you should see the themeswitcher below and a click on the link below that should give you a dalog box IFRAME:

jQuery UI IFRAME dialog box example

alternatively you can see it at standalone jQuery UI IFRAME dialog box example.

Fetching Servlet Filter init parameters from a properties file with Spring

Mon, 08 Jun 2009 14:10:20 GMT

A while ago I wrote some code and thought it a neat trick but totally forgot about it until recently. I am writing this blog entry, firstly to share the idea and secondly to see if somebody can give an alternative using only Spring classes (which would deepen my understanding). Using Spring's DelegatingFilterProxy it is possible to hand off creation of servlet filters to a bean defined in Spring's application context. This is very useful if you want to inject Spring managed beans into a your servlet filters.

I am using the DelegatingFilterProxy mechanism to configure my servlet filter init parameters and in conjunction using PreferencesPlaceholderConfigurer so these come from a properties file. This means I can easily switch between prod and dev environments without having to modify web.xml (I could even change the authenticationFilter implementation to something else but that is a different story!). My aim here is to minimize the number of files I need to edit when moving between prod and dev environments. I hope somebody else finds this approach useful.

As an example I am using the Yale CAS Filter, which is considered a little long in the tooth now (but I'm still using it). It makes for a good example because there are numerous filter properties that you might want to change. Even the most up to date version of the JA-SIG CAS Filter could potentially benefit from using my approach.

web.xml

    ...
    <filter>
        <filter-name>authenticationFilter</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>authenticationFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    ...

applicationContext.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	   xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <bean class="org.springframework.beans.factory.config.PreferencesPlaceholderConfigurer">
        <property name="location" value="/WEB-INF/dev.properties" />
    </bean>

    <bean id="authenticationFilter" class="edu.bristol.web.ParameterPassingFilterProxy">
        <property name="parameters">
            <map>
                <entry key="edu.yale.its.tp.cas.client.filter.loginUrl" value="${cas.loginUrl}" />
                <entry key="edu.yale.its.tp.cas.client.filter.validateUrl" value="${cas.validateUrl}" />
                <entry key="edu.yale.its.tp.cas.client.filter.wrapRequest" value="${cas.wrapRequest}" />
                <entry key="edu.yale.its.tp.cas.client.filter.serverName" value="${cas.serverName}" />
                <entry key="edu.yale.its.tp.cas.client.filter.renew" value="${cas.renew}" />
            </map>
        </property>
        <property name="targetBeanName" value="casFilter" />
    </bean>

    <bean id="casFilter" class="edu.yale.its.tp.cas.client.filter.CASFilter"/>

</beans>

The extra class that I added to make this work is available from ParameterPassingFilterProxy.java you are free to use it as you wish.

What would Hibernate do? Avoidance of hbm2ddl.auto=update in production

Thu, 14 May 2009 21:18:51 GMT

For the past 9 months I have been using Hibernate Annotations (along with the Spring Framework) to build my development database. Although I have a reasonably strong grasp of SQL I would still not consider myself fluent. Hibernate does all the hard work for me. Truth be told, there is a substantial learning curve to mastering mapping entity bean associations/relationships with Hibernate annotations. However once you finally develop an understanding (or find enough examples of what you want) it is very easy to continually evolve a data model throughout system development. Using annotations in conjunction with a suitably crafted import.sql file I can go from zero to system in no time. So after several months' development I am on the brink of having a production ready database containing precious real data that I do not want to loose. Should I take the risk of using "hbm2ddl.auto=update" to incorporate last minute database changes? I think not. I would not do this and this is not because I don't trust Hibernate but more because I do not trust myself. If I accidentally used hbm2ddl.auto=create (as I do regularly in my development instance) then bang goes my production database and all the data it contains.

So I wrote a small program to let me see what Hibernate would do if I ran an update without the associated risk of actually performing an update. I have a Spring applicationContext.xml which contains something like the following (note the complete absence of hbm2ddl.auto property setting):

<bean class="org.springframework.beans.factory.config.PreferencesPlaceholderConfigurer">
    <property name="location" value="jdbc.prod.properties" />
</bean>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName">
        <value>${jdbc.driverClassName}</value>
    </property>
    <property name="url">
        <value>${jdbc.url}</value>
    </property>
    <property name="username">
        <value>${jdbc.username}</value>
    </property>
    <property name="password">
        <value>${jdbc.password}</value>
    </property>
</bean>
<bean id="sessionFactory"
    class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
    <property name="hibernateProperties">
        <props>
            <prop key="hibernate.dialect">${hibernate.dialect}
            </prop>
        </props>
    </property>
    <property name="annotatedClasses">
        <list>
            <value>edu.bristol.entity.Tom</value>
            <value>edu.bristol.entity.Dick</value>
            <value>edu.bristol.entity.Harry</value>
        </list>
    </property>
    <property name="dataSource" ref="dataSource" />
</bean>

Now for my program, one thing that I have noticed is that update scripts that Hibernate would create will add new fields to a database but will not delete existing columns (even if these have been removed from the annotated entity). It makes a good deal of sense not to delete columns from a production database without knowing exactly what you are doing so this is a good thing!

import java.sql.Connection;
import java.sql.SQLException;
import org.hibernate.HibernateException;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import org.hibernate.dialect.Dialect;
import org.hibernate.tool.hbm2ddl.DatabaseMetadata;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.orm.hibernate3.HibernateCallback;
import org.springframework.orm.hibernate3.HibernateTemplate;
import org.springframework.orm.hibernate3.LocalSessionFactoryBean;

public class AcquireScripts {

    public static void main(String[] args) {
        ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        // ampersand is very significant - it means get me an
        // instance of the beanfactory and not give me a bean
        LocalSessionFactoryBean sfb = (LocalSessionFactoryBean) context.getBean("&sessionFactory");
        Configuration cfg = sfb.getConfiguration();
        Dialect dialect = Dialect.getDialect(cfg.getProperties());
        //printDropSchemaScript(cfg, dialect);
        //printSchemaCreationScript(cfg, dialect);
        printSchemaUpdateScript((SessionFactory) sfb.getObject(), cfg, dialect);
    }

    private static void printSchemaCreationScript(final Configuration cfg, final Dialect dialect) {
        String[] schemaCreationScript = cfg.generateSchemaCreationScript(dialect);
        for (String stmt : schemaCreationScript) {
            System.out.println(stmt + ";");
        }
    }

    private static void printDropSchemaScript(final Configuration cfg, final Dialect dialect) {
        String[] dropSchemaScript = cfg.generateDropSchemaScript(dialect);
        for (String stmt : dropSchemaScript) {
            System.out.println(stmt + ";");
        }
    }

    private static void printSchemaUpdateScript(final SessionFactory sf, final Configuration cfg, final Dialect dialect) {
        HibernateTemplate hibernateTemplate = new HibernateTemplate(sf);
        hibernateTemplate.setFlushMode(HibernateTemplate.FLUSH_NEVER);
        hibernateTemplate.execute(
                new HibernateCallback() {
                    public Object doInHibernate(Session session) throws HibernateException, SQLException {
                        Connection con = session.connection();
                        Dialect dialect = Dialect.getDialect(cfg.getProperties());
                        DatabaseMetadata metadata = new DatabaseMetadata(con, dialect);
                        String[] schemaUpdateScript = cfg.generateSchemaUpdateScript(dialect, metadata);
                        for (String stmt : schemaUpdateScript) {
                            System.out.println(stmt + ";");
                        }
                        return null;
                    }
                });
    }
}

Notice the cunning use of the ampersand to acquire an instance of the LocalSessionFactoryBean rather than the actual SessionFactory itself. So there we have it, all of the cleverness of Hibernate annotations working out what SQL we might need to update our database but none of the risk.

I am experimenting with a hosted blog

Wed, 06 May 2009 08:32:28 GMT

My "other blog" is located at http://markmclaren.blogs.ilrt.org/. I'm looking to see how I get on with a more restricted environment!

An alternative to req:isUserInRole

Thu, 15 Jan 2009 11:56:42 GMT

For me, HttpServletRequest's getRemoteUser() and isUserInRole(role) have always felt like the right place to obtain user information in a web application. My experience with JASIG CAS filter and SecurityFilter has taught me that it is easy to create a servlet filter and drop in a request wrapper (HttpServletRequestWrapper) and create a method to set the remoteUser value. Couple this filter with something like Spring's DelegatingFilterProxy and it is easy obtain user details from some dependency injected external database.

Once the remoteUser value exists in the wrapped request you can acquire the details in a JSP page using JSTL e.g:

<c:out value="${pageContext.request.remoteUser}"/>

or with simple expression language alone (JSP 2.4+), e.g:

${pageContext.request.remoteUser}

The question is how to obtain the role information for a user. Jakarta's Request tag library enables you to make use of role information.

<req:isUserInRole role="admin">
	<h1>Hello Admin User</h1>
</req:isUserInRole>

For some reason the request tag library is now deprecated. Of course you can still use it (and it is in the Maven repository) but there is something of a stigma associated with using deprecated code! So I have come up with an alternative. The issue is that it is not easy to invoke methods with parameter arguments from expression language. You cannot simply call:

${pageContext.request.isUserInRole('admin')}

Using expression language you can access scoped variables, arrays, lists and maps. Most of the time this data will be acquired and stored in some scope prior to loading the JSP page (such as in a typical MVC application). However, I have discovered that you can acquire runtime generated responses from a Map using Commons Collection's LazyMap and this technique can be used to effectively perform a user role lookup. I added the following method to my request wrapper (and made sure the request wrapper was publically accessible):

public Map getIsUserInRole() {
    Transformer factory = new Transformer() {
        public Object transform(Object mapKey) {
            return isUserInRole((String) mapKey);
         }
    };
    Map lazyMap = MapUtils.lazyMap(new HashMap(), factory);
    return lazyMap;
}

and this means I can now access role information in a way that looks very much like a direct call to request.isUserInRole(role).

${pageContext.request.isUserInRole['admin']}

Using an idea that Matthew Sgarlata had for the request tag library it is even possible to include support for multiple role queries.

public Map getIsUserInRole() {
    final String ROLE_DELIMITERS = ", \t\n\r\f";
    Transformer factory = new Transformer() {

    public Object transform(Object mapKey) {
           StringTokenizer tokenizer = new StringTokenizer((String) mapKey, ROLE_DELIMITERS);
           boolean result = false;
           while (tokenizer.hasMoreTokens() && !result) {
               if (isUserInRole(tokenizer.nextToken())) {
                   result = true;
               }
           }
           return result;
           }
     };
     Map lazyMap = MapUtils.lazyMap(new HashMap(), factory);
     return lazyMap;
}

and the expression language becomes:

${pageContext.request.isUserInRole['admin,staff']}

and this can be easily negated:

${!pageContext.request.isUserInRole['admin,staff']}

Sample WAR with source code available (Assuming Java 1.5+ and Maven build "mvn compile war:war").

Update

As an update to this, I am now using the above technqie with what I call a ClearingLazyMap. This class implements the LazyMap interface but does not cache any values when they are fetched. This is necessary in order to pick up the most recent database updates, see also LazyMap that always calls transform, good idea?

Re-inventing ORM, annotations re-invented for databases!

Wed, 05 Nov 2008 12:25:24 GMT

I am working on a web application where one of the requirements is that I use an in-house Java database access framework. Personally I would prefer to use something that complements Spring and that makes my life easier such as Hibernate Annotations, iBATIS or even Spring JDBCTemplates but requirements are requirements.

One of the problems I face is that I need to re-invent a lot of ORM wheels. The framework is very similar in essence to iBATIS. All the SQL is stored in external XML configuration files. The framework conducts the mappings conversion from ResultSets to lists of beans (using commons-beanutils). As such, like iBATIS there is plenty of scope to generate most of the repetitive Java code (interfaces, implementations, facades) and configuration files (SQL CRUD). I have previously experimented with the Middlegen code generation with iBATIS. Middlegen code is a little long in the tooth, as a project it seems to have stagnated back in 2005 (I suppose iBATOR and Hibernate Tools have long since superseded it). That said, because Middlegen is based on Velocity templates it is very flexible and perfect for this kind of thing. I was able to port my previous iBATIS code generating templates to produce suitable Java code for use with the in-house framework.

I have managed to get some quite sophisticated code generated. Apparently "Lazy Loading is easy", so I am attempting to implement that using CGLIB in my DAO. I have also produced a method that is similar to Hibernates's SaveOrUpdate method. A given entity may have two kinds of relationship; target one (OneToOne, ManyToOne) or target many (OneToMany). I have no ManyToMany relationships and this is deliberate!

How my SaveOrUpdate works is derived from some code I found in iBATIS in Action (By Clinton Begin, Brandon Goodin and Larry Meadors, Published by Manning). In section 5.3.2 Updating or deleting child records the following method is suggested:

public void saveOrder(SqlMapClient sqlMapClient, Order order) 
throws SQLException {
  if (null == order.getOrderId()) {
    sqlMapClient.insert("Order.insert", order);
  } else {
    sqlMapClient.update("Order.update", order);
  }
  sqlMapClient.delete("Order.deleteDetails", order);
  for(int i=0;i<order.getOrderItems().size();i++) {
    OrderItem oi = (OrderItem) order.getOrderItems().get(i); 
    oi.setOrderId(order.getOrderId());
    sqlMapClient.insert("OrderItem.insert", oi);
  }
}

The above method addresses the target many relationships but does not address the target one relationships. My method works more like this:

Iterate through all the target one entities and SaveOrUpdate these. Inserting any generated ids into the current entity.
Save the current entity data fields
Iterate through all the target many relationships and SaveOrUpdate these.

At this point I got a little stuck. I found that relatively often my target one relationships should not be the subject of further SaveOrUpdates. The characteristic of these relationships is when the data is fairly static and mostly provides the conent of drop-down lists. When you make a selection from a such a list you do not usually need to update the list itself!

Essentially, Middlegen generates everything based on the contents of the database. For these relationships I needed some way to designate the code generation behaviour for certain database columns.

In Java Persistence API implementations, like Hibernate Annotations, this kind of behaviour is very easily represented by using @Column(insertable=false, updatable=false). I needed a way for Middlegen to acquire this information from the database. Then I had a brainwave, in the most recent version of Middlegen (from the CVS) you can "getRemarks" for tables and columns. Database remarks can be acquired from DatabaseMetaData. The unfortunate thing is that I am using an Oracle database which AFAICT uses a non-standard treatment of "remarks". It turns out that the default behaviour of Oracle drivers is not to populate the DatabaseMetaData with remarks. In Oracle remarks are contained inside two special tables; user_tab_comments and user_col_comments. You can override the default behaviour of Oracle driver to populate remarks, this can be done at the BasicDataSource (using addConnectionProperty("remarksReporting", "true")) or on a OracleConnection (using setRemarksReporting(true)).

Armed with this information I can "annotate" database columns, so I can use something like this:

COMMENT ON COLUMN <table>.<column> IS 'insertable=false, updatable=false';

I tweaked MiddlegenPopulator to allow it to acquire remarks for Oracle from the DatabaseMetaData. The database now contains all the information I need to generate my DAO code. I can now tweak my DAO generation templates to miss out the SaveOrUpdate code for target one relationships which match the column comment of 'insertable=false, updatable=false'.

Simple huh? Or maybe just plain scary... annotations with databases!