public class Person {

  private Long id;
  private String firstName;
  private String lastName;
}

public class User extends Person {

  private String userName;
  private String password;

}

public class Customer extends Person {

  private int creditLimit;

}

public class Employee extends Person {

  private Date beginDate;
  private Date endDate;

}

The classic problems here are that a customer may not always be a person, and a person may be both a customer and a vendor and possibly even be an employee and user. It also ignites the age old debate of whether a user must be an employee or all employees are also users. Using inheritance severely restricts us by taking away our one chance to inherit from a single class and limits our future plans since we are claiming some hard rules such as “every user is a person”.

Also, how do we handle a person that leaves the company and comes back? Do we have two different instances of this person in the system? For that matter, most Person instances will be duplicated if a person is a customer and a user and employee. This also leads to problems with things like name changes where one version gets updated but the other doesn’t.

Role your own

One common solution to this problem is to let the Person entity have a collection of roles that they perform so they can be either a user,an employee, a customer or vendor at the same time. This does solve the problems of not having to worry about inheritance hierarchies and whether a user is an employee or vice versa and also lets a person play all those roles at once. However, it only works where you know that every user, customer, vendor or employee will be a person.
It’s also not very clear how we should reference these entities. If I have an order and need to reference a customer, do I reference the person or the persons customer role?

Compose Yourself

Alternatively you can use composition to model the relationship instead of inheritance. We can define a Person class which models just a person and we model Customers and Employees as separate classes that encapsulate the information specific to that role and has a reference to the person associated with it.The benefit here is that the different classes do not have to be subclassed from the Person class which lets us inherit from whatever we want.

public class User {

  private Long id;
  private String userName;
  private String password;
  private Person person;
}

and

public class Customer {

  private Long id;
  private Person person;
  private int creditLimit;
}

public class Employee {

  private Long id;
  private Person person;
  private Date beginDate;
  private Date endDate;
}

We don’t have to worry about whether Employee should inherit from a User or vice versa since they are entirely different entities but they reference the same person instance. We still have the ability to check for things like users that are employees by finding users and employees that have a matching person reference. Modeling for each of the entities is kept specific to what the entity represents. A customer contains customer information and an employee contains employee information with only a single reference to the person it is representing.

This solves our original problems, but also gives us far more in return. It is a far more flexible design because we can expand the definitions of the classes beyond the hard restriction that every customer must be a person. Let’s consider a situation where the developers have been asked to allow businesses to also be defined as customers in the system. With the Customer subclassing from Person design it would be a nightmare to change the code to accommodate this. On the other hand, if we designed Customer to use composition, we can easily resolve the problem.

public abstract class AbstractCustomer {

  private Long id;
  private int creditLimit;
  public abstract String getName();
}

We can create a person based customer by subclassing it and adding a reference to the person.

public class PersonCustomer extends AbstractCustomer {

  private Person person;

  public abstract String getName() {
    return person.getName();
  }
}

For a company based customer, we can again subclass it, this time adding a Company reference.

public class CompanyCustomer extends AbstractCustomer {

  private Company company;

  public abstract String getName() {
    return company.getName();
  }
}

Notice that in the abstract base class, we define the getName() method to return the name of the customer. This is made abstract and must be implemented in subclasses specific to the type of customer we are implementing. As a general rule, like any inheritance, common attributes that apply to all types of the entity should go in the base class because then you will be able to call those methods on references to the entity as the base class type instead of having to use a more specific subclass type. For example

  String msg = "Hi There "+customer.getName();

is much cleaner than

  String msg = "Hi There ";

  if (customer instanceof PersonCustomer) {
    msg = msg+((PersonCustomer)customer).getPerson.getPersonName();
  }

  if (customer instanceof CompanyCustomer) {
    msg = msg+((CompanyCustomer)customer).getCompany.getCompanyName();
  }

Another nice effect of this is modularity since you can add new customer types and the old queries will work the same way. For example, if you start with PersonCustomer you might have a query which lists the customers with a certain credit limit.

select c from Customer c where c.creditLimit > 500

If you suddenly add the CompanyCustomer class to the application, the query will still work and will now include company based customers in the list. Remember, the more attributes defined on the base class, the more attributes you will be able access or query on when obtaining instances as the base class. However, note that code driven attributes such as the getName() example above cannot be used for querying in JPA since the attribute does not resolve to a database field. To query by person name you would have to drop down to using the actual class name to query the name fields in the person reference.

Unique People, non-unique references

If an employee leaves the company and comes back, we can deal with this much easier because we can set the end date for the existing Employee instance when they leave and when they come back, we can create a new employee instance that references the same Person entity. We still only have one Person instance that is referenced by both Employee instances and thus there is no duplication. This kind of modeling is not only more accurate in that one person was an employee on two different occasions, but it also provides a form of auditing trail for that person. If you store the Employee reference, you can still use either the person or the employee id to search for data. If you wanted to see what orders this specific employee had filled in, you can search using either the employee id which would get the orders for this version of the employee only, or you could match based on the person id and see what orders that person had ever filled in as either employee instance. This also reflects the real world better since there is only ever one person, but they could have multiple periods as an employee.

Modeling with JPA

It is fairly easy to model the basic composition in JPA by adding a @ManyToOne annotation to the entity reference (in this case the person).

If you plan on creating subclasses that are backed by different entities (i.e. PersonCustomer and CompanyCustomer) then you have to choose between different inheritance strategies. If there only a few differences between subclasses, you can probably just use a single table. If there are bigger differences between the subclasses, you might want to use a joined table inheritance strategy while keeping the core attributes of the parent class in the main table.

For legacy databases, you could be faced with the problem that the referenced entity id, such as the company or person id in the customer subclass, is stored in the same field in the database record. You can use the same field name for the reference in the subclasses and JPA will work with it.

public class PersonCustomer extends AbstractCustomer {

  @ManyToOne
  @JoinColumn(name="REF_ID")
  private Person person;

}

public class CompanyCustomer extends AbstractCustomer {

  @ManyToOne
  @JoinColumn(name="REF_ID")
  private Company company;

}

Obviously, this method eliminates the opportunity to use foreign keys since a foreign key cannot reference two different tables. New designs should not use this method for this reason even though JPA allows it. If you let JPA drop and create the tables for you, with Hibernate at least, you will end up with a foreign key on the REF_ID field to either the person or company table that will be incorrect when you assign the other subclass type to it. Through luck, it may not raise an error the first time around (if you happen to have an instance of one entity that has the same Id as the other entity type) but it will at some point.

If you really need this design, then you can just build the tables yourself without the foreign key, but you should use a separate field even though it means that each record will have blank field in it. With a separate or join table inheritance strategy, you have no choice but to use separate fields for the references.

A technique with many uses

This technique has many applications, but I haven’t really seen it discussed that much. Obviously, most published application examples (i.e. Pet store or my own Issue Tracker) are trivial or incomplete so they don’t really require this level of attention to modeling detail. However you start to find all sorts of places this technique can be used for larger domain models either to provide functionality needed now or a flexible design to meet future requirements. Obviously, we don’t want to use this for everything in case we want to extend any object in our model, but refactoring models once you have gone live can be problematic as it not only involves code refactoring, but database refactoring as well. Adopting this technique early (i.e. pre production) in places it is likely to be needed can save a lot of headaches later on.

As another example, let’s say you wanted to define a Location which is basically an address and a few other attributes. These locations can be used for all sorts of things in various places in the application. We already have an Address class used throughout our code and we can embed it in our Location.

public class Location {

  @Embedded
  private Address address;

  private Date createdOn;
  private String description;

}

Half way through your project you find that since this location class is used everywhere, the needs have changed somewhat and in some places need to have a dynamic address that belongs to a person and needs to be updated when the persons address changes, and some places need a static fixed address that never changes (i.e. delivery address an order was sent to which never changes).

We can easily implement this by creating a Location class that is subclassed into the different implementations that source the address from different places.

public abstract class Location {

  public Address getAddress();
  private String description;
  private Date createdOn;

}

public class FixedLocation extends Location {
  @Embedded
  private Address address;

  public Address getAddress() {
    return address;
  }
}

public class PersonLocation extends Location {

  @ManyToOne
  private Person person;

  public Address getAddress() {
    return person.getPrimaryAddress();
  }

}

Not only have we provided a solution for our fixed and dynamic address problem, since FixedLocation will store the address internally while the others will dynamically obtain the latest address from the Person, but we have provided a structure that will allow us to turn any entity into an address provider for our Location class. In some ways, we are using it as more of an adapter pattern since the address sources no longer have a common type. We are using an adapter pattern to make the different implementation sources fit with our Location interface.

I have found a number of uses for such compositions/adapters in places where inheritance would have severely limited my options or provided some difficult challenges, and by implementing this concept I’ve been able to make my models far more flexible and be able to accommodate new needs quickly.

As a refresher, in our last part, we had an application that obtained a list of items, validated them and took a specific action when an invalid item was found. Lets say in the future we want to expand our system to handle all sorts of things happening when we find an invalid item. This could range from an email being sent, changes made to other data (i.e. an order canceled) or storing a list of rejections in a file or database table. To completely decouple the implementation we can use events. Events are raised by the event producer and subscribed to by event observers. Like most of CDI, event production and subscription is type safe and allows qualifiers to determine which events observers will observe.

Luckily we don’t have to change our application much to implement this, we just provide an implementation of the ItemErrorHandler that raises the event when it handles the item. We will inject an instance of the Item error handler called EventErrorHandler and create a @Notify qualifier to select it for injection.

@Retention(RetentionPolicy.RUNTIME)
@Target({FIELD,METHOD,PARAMETER,TYPE})
@Qualifier
public @interface Notify {}

@Notify
public class EventItemHandler implements ItemErrorHandler {

    @Inject
    private Event<Item> itemEvent;

    public void handleItem(Item item) {
        System.out.println("Firing Event");
        itemEvent.fire(item);
    }
}

In this item handler, we inject an instance of an Event where the event payload will be an Item. The event payload is the state data passed from the event producer to the event observer which in this case passes the rejected Item. When the invalid item is handled, we fire the event and pass in the invalid item we received. This event based item handler is injected the same as any other item handler would be so we can swap it in and out whenever we need to and also can substitute it during testing. We created a @Notify qualifier annotation to identify this error handler for injection and can use it in our item processor by adding it to the injection point.

    @Inject
    @Notify
    private ItemErrorHandler itemErrorHandler;

If we deploy this now, we will see that when the item processor hits invalid items, the event based item error handler fires the event. Currently though we don’t have anything observing the event. We can fix this by creating an observer method which is the only thing needed to observe an event. We can still re-use our existing item processors by adding an event observer method to the implementations which just calls the error handler method. For example, to make our FileErrorReporter respond to the event, we add the following observer event.

public class FileErrorReporter implements ItemErrorHandler,Serializable {

    public void eventFired(@Observes Item item) {
        handleItem(item);
    }
    ....
    ....

If you run the application now, you will see that the events are fired on the invalid objects, and the item information is being saved when this event is fired. You will also note that the lifecycle events are being observed.

INFO: Firing Event
INFO: Creating file error reporter
INFO: Saving eedemo.Item@1f84b46 [Value=34, Limit=7] to file
INFO: Closing file error reporter
INFO: Firing Event
INFO: Creating file error reporter
INFO: Saving eedemo.Item@2656da [Value=89, Limit=32] to file
INFO: Closing file error reporter

Note that the file error reporter bean is created each time the event is raised which may or may not be what we want. In this case, we don’t want to create the bean new each time since we don’t want to open and close the file for each item. We still want to open the file at the start of the process, and then close it once the process it completed. In this case, we need to consider the scope of the FileErrorReporter bean which doesn’t have a scope defined. When no scope is defined, CDI defaults it to the default pseudo dependent scope. What this means in practice is that the bean is created and destroyed over a very short space of time, typically over a method call. In our case here, the bean is created and destroyed for the duration of the event being fired. To fix this, we need to lengthen the scope of the bean by manually adding a scope annotation. We will make this bean @RequestScoped so once the bean is created the first time the event is fired, it will remain created for the duration of the request. Also, for any injection points that this bean is qualified to be injected to, the same bean instance will be injected. Here is the log when we make our scope change to the bean. Note that the bean is still only created when the event is fired.

INFO: Firing Event
INFO: Creating file error reporter
INFO: Saving eedemo.Item@1380c08 [Value=34, Limit=7] to file
INFO: Firing Event
INFO: Saving eedemo.Item@1b44f96 [Value=89, Limit=32] to file
INFO: Closing file error reporter

Let’s take the events example a little further. Right now we are observing any event for an item but chances are, there may be different types of events in the system for the items. We want to be specific in which observers subscribe to which events. Luckily CDI provides for this in a similar manner to how we determine suitable beans for injection points by using typing and qualifiers.

First, lets create a problem for ourselves by firing events off for each item we validate by adding the following code to the item processor.

    @Inject
    private Event<Item> processorEvent;

    public void execute() {
        List<Item> items = itemDao.fetchItems();
        for (Item item : items) {
            processorEvent.fire(item);
            if (!itemValidator.isValid(item)) {
                itemErrorHandler.handleItem(item);
            }
        }
    }

This will fire an event for each item we process, but we don’t want the invalid item handler to subscribe to each of those events. If we do, we will see output like the following :

INFO: Creating eedemo.EventItemHandler_$$_javassist_748
INFO: Creating file error reporter
INFO: Saving eedemo.Item@6d0baf [Value=34, Limit=7] to file
INFO: Creating eedemo.EventItemHandler
INFO: Firing Event
INFO: Saving eedemo.Item@6d0baf [Value=34, Limit=7] to file
INFO: Saving eedemo.Item@1087300 [Value=4, Limit=37] to file
INFO: Saving eedemo.Item@11674c9 [Value=24, Limit=19] to file
INFO: Saving eedemo.Item@de163a [Value=89, Limit=32] to file
INFO: Firing Event
INFO: Saving eedemo.Item@de163a [Value=89, Limit=32] to file
INFO: Closing file error reporter

For each item, the file item handler observer is being called for each item because we aren’t distinguishing the kind of events fired when the item is processed and the kind of event fired when an invalid item is found. To differentiate between them we will create an @Invalidate qualifier to qualify the event for invalid items. This annotation will be placed on the event injection point and also on the observation point method.

@Notify
@RequestScoped
public class EventItemHandler implements ItemErrorHandler {

    @Inject @Invalidated
    private Event<Item> itemEvent;

    public void handleItem(Item item) {
        System.out.println("Firing Event");
        itemEvent.fire(item);
    }
}

@Save
@RequestScoped
public class FileErrorReporter implements ItemErrorHandler,Serializable {

    public void eventFired(@Observes @Invalidated Item item) {
        handleItem(item);
    }

    ....

}

If you run the code now, you will see that we no longer call the file save handler for each item, even though we are firing the event for each item.

INFO: Firing Event
INFO: Creating file error reporter
INFO: Saving eedemo.Item@1e3aa22 [Value=34, Limit=7] to file
INFO: Firing Event
INFO: Saving eedemo.Item@172940f [Value=89, Limit=32] to file
INFO: Closing file error reporter

You can add an event observer to the item processor just to see the events are still being raised and can be observed.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    ....

    public void observeItemEvent(@Observes Item item) {
        System.out.println("Item event observed for item "+item);
    }
}

This will print a message whenever an event is fired so you can see that there is a difference between the two event subscribers and also that the more general version of the observer sees all events related to the item.

Events are a great way to decouple parts of the system in a modular fashion as you can add pieces that will subscribe to events with the event producer unaware of the observer as opposed to the even producer having to call the observer manually when events are not used. For example, if someone updates an order status, you could add events to email the sales rep, or notify an account manager if a tech support issue is open for more than a week. These kinds of rules can be implemented without events, but events make it easier to decouple the business logic. Additionally, there is no compile or build time dependency and you can just add modules to your application and they will automatically start observing and producing events. Additionally, observers and producers know nothing about each other, nor do they require any configuration for them to do so.

Scheduling the Processing

One last tidbit before we move on to creating CDI driven JSF apps is that for now we are running our code from a button in a JSF page but typically this is something that would get fired off on a regular basis. With the power of the EJB 3.1 scheduler we can do just that in a new class with few lines of code. We’ll create a new stateless EJB into which we’ll inject our ItemProcessor and add a method to call the execute() method which will be called at a scheduled time.

@Stateless
public class ScheduledProcessor {

    @Inject
    private ItemProcessor itemProcessor;

    @Schedule(hour="07",minute = "00")
    public void execute() {
        System.out.println("executing scheduled job!");
        itemProcessor.execute();
    }
}

This makes use of the new EJB 3.1 @Schedule annotation and will schedule this method to be called every morning at 7am. You could make it on the hour every hour, or you could use the EJB timer service to implement your own timeout. We inject the same ItemProcessor implementation we have been using all along and call the execute() method. That is a pretty powerful transformation letting us re-use our existing code and easily incorporating EJB services with POJO managed beans into an EJB needing only a few lines of code.

Note : If you actually implement this and run it, it won’t work because of a Weld 1.0 bug whereby the request scope isn’t active during calls to EJB timeouts (see here for details) so you’ll have to wait until Weld 1.01 which should be out fairly soon.

IDE Support – I would like to get as much IDE support as possible for auto completion, code validation and general helpfulness.

Resume Building – How much demand is there for the skills? I’m looking to bolster my skills that have wide adoption in the industry. As this is an important factor, it also means I probably won’t be choosing a framework that I am already very familiar with. I’ll be using job trends and opinion to determine the industry support for the frameworks. I know job sites aren’t the best measure, especially since many ads are stuffed with buzzwords so they appear in searches even if there is no JSF, JAXB or JAX-WS involved. However, the fact that they are included at all indicates some kind of market penetration of the technology.

Ajax Support – How well does it support Ajax natively out of the box as opposed to requiring third party libraries and are there de-facto standard libraries for that framework if they are needed.

Templating / Layout – How are pages built and organized to enable reusable HTML without using include statements everywhere or some other mechanism which will require every page to be edited if the layout is changed. I think facelets is the best page layout library out there as it pulls the template into the page and then pushes the content from the page into the template making separate files optional. Tiles requires separate definition files and does a similar thing outside of the page being rendered. Sitemesh is non invasive and works by decorating existing pages as they are sent to the client. In terms of writing actual pages, the choices are Jsp, Velocity and Freemarker, of which JSP and Velocity are the two most in demand.

Completeness – How much is in the framework out of the box without requiring additional libraries for core functionality. Obviously, you are going to need libraries for things like data access, but the framework should be able to put text in a page without requiring third party libraries. One other aspect of this is how easy it is to get up and running without having to get different pieces configured and talking to each other. Some frameworks discussed here like Spring MVC and JSF are not meant to be complete frameworks but a framework onto which to build other frameworks (like Servlets). In these cases, the frameworks are expanded by third party libraries so completeness is not so much a factor here. Third party libraries integrated as part of the stack is acceptable (i.e. Sitemesh in Grails and Richfaces in Seam).

Custom Paginated Tables with Sortable Columns – This is my barrier for determining how powerful and easy a framework is to use. Simple CRUD is trivial to write, it’s like hello world for the web so I usually go for a more robust litmus test by writing some pagination code. Action frameworks require you to chug all the parameters backwards and forwards and handle your own binding and determining whether a page was selected or next/previous was clicked while Component frameworks handle most of that for you. For the same reason, clickable columns can be a real pain. For bonus points, how easy is it to implement multiple paginated / sortable tables?

Statefulness – Can we integrate some kind of stateful mechanism in there (i.e Spring Web Flow) cleanly? There are a few scenarios where I will need a stateful workflow in the application.

Third Party Support and integration – One annoying aspect of java web development is all the pieces and parts that need to be strung together and then you have to get them to play nicely. This is really about the path of least surprise, and not having to deal with issues because I add libraries that don’t have special mechanisms for working with each other.. I.e Spring MVC embraces Tiles, but how much of a hassle is it to incorporate Velocity with Tiles? This issue is also somewhat redundant for those frameworks that include built-in solutions for most needs.

The application is going to be moderate in size, but hopefully growing as time goes on. For that reason, I’m looking for something flexible enough to grow and refactor later on. Initially, I’m also looking for something lightweight and will be looking to deploy it on Tomcat primarily due to ease of hosting.

Action or Component Based

I find Action frameworks are great for catalogs and simple CRUD pages but when you start getting to more complex web applications pages, things get much tricker. Take for example a search page with 10 search parameters, suddenly you find yourself having to attach 10 parameters to the next/previous/first/last result links or using javascript funkiness to modify form contents to change the form state and post the form. Add column ordering and things get pretty messy quickly. In my mind, For a web application, any search pages (or other pages that require pagination or other common interface elements) should be trivial to write within minutes. Obviously, if you are Google and your main business is that one search page, you can afford to spend a little more time on it and be as choosy as you like on how to implement it. However, it never fails to amaze how much code people will write to create a single page demonstrating how to do some simple function in a non-reusable way. User interface elements like pagination and column ordering should be totally reusable.

The Contenders

Here are the contenders in no specific order

• Seam with JSF
• Wicket
• JSF
• Grails
• Spring MVC with JSP
• Spring MVC with JSF

First lets look at the job trends for these different frameworks :

spring java, ejb java, jsf java, "spring mvc" java, wicket java, seam java, grails java Job Trends

spring java jobs – ejb java jobs – jsf java jobs – "spring mvc" java jobs – wicket java jobs – seam java jobs – grails java jobs

We can see a sort of multi-tier system in place for different frameworks. Spring and EJB both rank up there as first tier technologies. I’ve already had quite a bit of experience with both of these but Spring is at an advantage with regards to being lightweight and running in tomcat without having to worry about setting up an embedded EJB container. Writing something with EJB 6 might be a possibility, but I think it more likely I’ll try and use Spring.

Now lets consider the view frameworks :

jsf java, "spring mvc" java, wicket java, seam java, grails java Job Trends

jsf java jobs – "spring mvc" java jobs – wicket java jobs – seam java jobs – grails java jobs

Seam / JSF

I’ve had a lot of experience with these two so it’s easy to comment on. Great IDE support (probably the best), great out of the box support, but it can feel foreign to use on Tomcat where it doesn’t offer such a rich a developer experience. Great Ajax support, but not so great for the resume since I already have a lot of experience with Seam and there are very few Seam jobs out there.

JSF

Despite using Seam a lot, writing a straight JSF application is still quite different and poses a number of challenges. It might be a interesting using just JSF but I have most of that ground covered with my existing JSF work. JSF is in-demand though and this might be an opportunity to use it with other frameworks such as a Spring/Hibernate/JSF combination. It has great Ajax support with multiple frameworks available, but no decent IDE support even though JBoss Tools works well on plain JSF apps without Seam. It may also get frustrating since I’ll be having constant reminders of how easy things are when you use Seam. Facelets is a great templating framework, if not the best, and I’d probably go to JSF 2.0 so I can use annotated beans. For statefulness, I could add in Orchestra and pagination should be simple with JSF although I think Seam (or JBoss-El) added ways to call methods (with parameters) on beans passed in to facelets which made it really easy. I haven’t been able to duplicate that with in JSF or Spring Faces which could be a problem. One annoyance of JSF is the inability to suppress validation when you post the form back but don’t want to save it which you may want to do as part of a web flow where you want to save the contents, go to another page, come back and finish your data entry. The only solution is to manually perform validation when the form is finally saved and not use JSF validators which is a limitation and I don’t thing this was fixed in JSF 2.0.

Wicket

Wicket is a great component based framework with good ajax support, a fine grained stateful architecture and because of it’s emphasis on the java language, good IDE support. Some people don’t like the heavy use of java code to build web pages, but it’s a personal thing and I do enjoy it. However, the only thing holding it back for me is the poor industry adoption with very few Wicket jobs.

Grails

I tried to get back into Grails and again, I hit a number of snags. It’s a great framework, but I find it can be problematic. The IDE support was basic and I often had to clean the eclipse project then the grails project so it wouldn’t choke on old classes lying around. Netbeans also has Grails support, but was prone to hanging when you want to restart the server. It also lacked the refactoring / renaming features present in eclipse. I also found problems in the framework itself such as not being able to model embedded classes that contained a reference to another entity. Other times, inexplicably, when I called person.save() nothing would happen, no error, no messages, nothing. I don’t doubt it was my fault and something I did, but it is off putting and frustrating in a framework that won’t tell you when you have a syntax error.

Grails and Wicket seem like polar opposites in some ways. Wicket is all about type safety and strict java code checked by the IDE. Grails on the other hand doesn’t often know when you make a mistake because its a dynamic language. Developers shouldn’t have to write tests just to make sure you didn’t make any typo’s in your classes, people have spent a number of years and millions of dollars evolving IDEs to solve that very problem.

The dynamic language is all very nice, and Grails is a framework but when I’m building furniture, I don’t start out with aflat pack plywood cabinet and slowly replace each piece with half inch mahogany with hand cut dovetail joints in the name of being rapid and agile (umm, Agile Wordworking, there’s an idea). I can see the point, and for the most part, Grails is unobtrusive but I think for me, on this project, I’d rather start out with a workbench and some planks of mahogany and craft it from scratch.

Ajax support is excellent and it also has many plugins which are easy to install and use. Writing taglibs is a breeze and very intuitive. Even pagination was fairly simple and I especially liked the paginator tag that takes a map of parameter values to include on all the previous/next/page links. Again, things are scarce on the job front for Grails, but being such a unique and productive tool I think there is a great future for Grails which lowers the importance of current trends.

Grails also supports Spring Web Flow but I’m not sure it allows the use of flow scoped persistence contexts. Sitemesh is used for templating and offers a lot of features out of the box. Overall it’s very impressive and definitely still a contender.

Spring MVC with JSP

This is probably the one I was most eager to tackle as I think this one probably has the most potential. Spring and JSP have been largely adopted within the industry, but are they any good? I think Spring MVC is excellent, especially with the new Spring 2.5 Controller annotations and Web Flow integration. As usual with Spring, it provides a lot of flexibility and it sits on the Core Spring Framework. For templating, I can use Sitemesh, Tiles, and it includes support for velocity and free marker. It appears that using both Tiles and Velocity together isn’t straightforward resulting in this third party plugin to solve the problem.

Spring MVC doesn’t have any ajax support, Chapter 13 – Web MVC Framework of the Spring reference documentaton doesn’t even mention the word Ajax. Spring Web Flow has Ajax support but it requires the use of Tiles (or some other compatible templating library) for specifying page fragments to update. This is also requires that pages be designed in such a way that the Ajax updatable pieces are clearly defined in the page definition which is outside of the page being designed. With Richfaces you can create a fragment in the page just by using an output panel tag and giving it a name. Another problem with Spring Web Flow is the inability to use an Open Session In View alongside the Flow Managed Persistence context which means having to work around Lazy Initialization Issues in other ways. On the plus side though, you can make validation optional in Spring Web Flow if you are using the Spring Validators and not JSF.

Spring MVC with JSF / Spring Faces

If I couldn’t find a way to reconcile the problems with Spring MVC and JSP, this would be my backup as it solves a number of problems with using Spring MVC and JSP. It fixes the Ajax and templating issues since I can use a JSF based Ajax framework (IceFaces or Richfaces) and Facelets for superior templating. The only problems here is a resource issue for JSF and the fact that I have already worked with JSF extensively. However, I have found Spring Faces to be a great library to use with some nice extensions. While there are only a few jobs explicitly mentioning Spring Faces, there are many jobs involving Spring and JSF. While spring web flow de-couples your view from the back end, it can be a little too decoupled. For example, within a flow, to call a method from a command button and refresh some data requires you to call the method and return an action string that would trigger the refresh of the data in the web flow. In Seam, you can get away with just calling the method and then refreshing the data. Spring Web Flow, forces you to decouple that which makes for a lot more work when you have multiple links that can trigger a refresh of the data. It also doesn’t fix the open session in view / flow managed persistence context clash. Writing JSF pages outside of a web flow means having to work directly with Spring beans as Jsf backing beans as opposed to dealing with Spring Beans through the web flow. This isn’t a big deal though, it just means you have two separate styles of writing code. Even though Spring Web Flow lets you suppress validations for flow transitions, It doesn’t have any effect when you are using JSF for the view, only when you are using Spring validations.

Summary

Ultimately, it boils down to Grails or Spring MVC with JSP and probably Tiles and if I can’t find a solution there, Spring MVC with JSF. I f career/employment was not a factor, I would pick Wicket with Spring in a second, however, as I’m looking to bolster my resume and make sure my bona fides are in order for the more popular technologies.

All in all, it’s a difficult choice, but I’d love to get some more thoughts on the matter. I’m sure there are plenty of opinions on frameworks out there in The java community

public class GlassButton extends AbstractTexture {

	private final RGBAColor color;

	public GlassButton(RGBAColor color) {
		this.color = new RGBAColor(color);
	}

	public void getColor(double u, double v, RGBAColor value) {
		value.setColor(color);
	}
}

Next we’ll create our main class and add some code to create and render our texture.

public class Main {

	public static void main(String[] args) {
		RGBAColor color = RGBAColor.red();
		Texture texture = new Background(new GlassButton(color),RGBAColor.white());
		TextureViewer.show(texture);
	}
}

Ok, a fairly simple start, we create our texture with a red color over a white background and pass it to the viewer. If you save and run this, you should get a window with a start button, which will render the red texture when clicked. Let’s add a method to our texture to calculate where on the button the textures u,v co-ordinates are. We do this by calculating the distance from the center of the texture the U,V co-ordinates are. The value returned will range from 0..1 inside the circle and outside the circle, it will return 1+ and grow larger the further it gets from the center. This lets us determine what should appear for any given point on the texture. Since we want a border around the edge of the button, we will have to scale the u,v values so when the result ramps up to 1 before getting to the edge of the texture. Add the following method to the GlassButton class.

protected double calculateCircleRange(double u,double v) {
	//displace point
	u = u - 0.5;
	v = v - 0.5;
	//calculate distance
	double distance = Math.sqrt((u*u)+(v*v));
	//double it since the range will only be from 0 to 0.5
	return distance * 2;
}

We can verify this works by changing our get value method to return this value in the alpha channel.

public void getColor(double u, double v, RGBAColor value) {
	double range = calculateCircleRange(u, v) * 1.2;
	value.setColor(color);
	value.setAlpha(1-range);
}

We inverted the signal (1-range) so the color would be stronger at the center and weaker at the edge. Since the range goes beyond 1, then the value is truncated to the range 0..1 which is why the pattern repeats at the edge of the circle.

What we need to do is calculate the color based on the return value of this function. Values greater than 1 will result in rendering the shadow with a strength inversely proportional to the distance from the edge. For 0 to 1 values, we will render the button color and overlay the highlight onto it. We will also add an inner shadow in the range 0.7 to 1 with a strength based on the distance from the edge. The button color will consists of a base color which slowly transforms into a darker version of that base color the further down the button we go. The highlight is added as a lighter version of the base color with the alpha channel decreasing the further down the button we go. This has the effect of fading out the highlight the further down we go. Let’s flesh out a simple version to indicate where each piece is going.

public void getColor(double u, double v, RGBAColor value) {
	double range = calculateCircleRange(u, v) * 1.2;

	if (range > 1) {
		//render shadow
		value.setColor(RGBAColor.black());
		return;
	}		

	value.setColor(color);

	if (range > 0.7) {
		value.setColor(RGBAColor.yellow());
	}
}

This gives us a fairly predictable result, you can see where the button ends and the shadow starts and you can see which parts the inner shadow affects. We multiply the range value by 1.2 so we can shrink the circle down a bit to give us our margin around the edge for the shadow to sit in.

Time to add some actual colors to our template starting with the shadow. Our shadow is essentially the color black with the alpha ranging from 0.9 to 0 based on how far the point is from the edge of the button. We make the shadow fall off exponentially so the shadow becomes much lighter faster. Bear in mind that the range value for the shadow area is 1+ so we need to adjust the value into the 0..1 range.

public void getColor(double u, double v, RGBAColor value) {
	double range = calculateCircleRange(u, v) * 1.2;

	if (range > 1) {
		//render shadow
		value.setColor(RGBAColor.black());
		double shadow = Math.pow(2-range-0.1, 8);
		value.setAlpha( shadow);
		return;
	}		

	value.setColor(color);

	if (range > 0.8) {
		value.setColor(RGBAColor.yellow());
	}
}

We specified a white background in our main class and the shadow has a varying alpha value so the white background show through. We can also change the background to see how it looks on different colors.

Now would be a good time to set up the different colors we’ll be using in our button. We have our base color passed in to the constructor, and from that, we can calculate the darker button color and the lighter highlight color. Let’s add those in to the constructor first.

public class GlassButton extends AbstractTexture {

	private final RGBAColor color;
	private final RGBAColor darkerColor;
	private final RGBAColor highlightColor;

	public GlassButton(RGBAColor color) {
		this.color = new RGBAColor(color);

		//make a copy and darken it
		this.darkerColor = new RGBAColor(color);
		this.darkerColor.merge(RGBAColor.black(),0.5);

		//make a copy and lighten it
		this.highlightColor = new RGBAColor(color);
		this.highlightColor.merge(RGBAColor.white(),0.8);
	}

With our colors in place, we can start adding them to the final button image. We’ll start with the main button color which ranges from the base color to dark color as the v value increases and we evaluate pixels further down the image. This can be done with one line of code since we take the base color and merge the darker color based on the v value after we assign the base color to the value.

value.setColor(color);
value.merge(darkerColor,(v-0.1)*1.2);

We shift and scale the v value to try and make the color transformation apply across the whole face of the button which is scaled down. This gives as a gentle transformation across the face of the button.

The button has an inner shadow which gives us the impression that the edges of the button are bending away from us. The code for this looks at the circle range value and if greater than 0.8 adds the inner shadow based on the distance from the edge. To calculate this, we subtract the 0.8 and scale it to get a value in the range of 0 to 0.4 which is perfect since we don’t want a strong shadow.

		//add the inner shadow
		if (range > 0.8) {
			double shadow = (range-0.8)*2;
			value.merge(RGBAColor.black(),shadow);
		}

The last piece we need to add is the highlight which is rendered in the shape of an smaller circle that is offset upwards slightly. This means we can reuse our calculateCircleRange method to determine which points are in the smaller circle. Once we have determined whether we are in the highlight circle or not we will merge the highlight color based on the v value so the highlight fades out as we move down the button.

Here is the complete getColor method with the code to add the highlight at the end.

public void getColor(double u, double v, RGBAColor value) {
	double range = calculateCircleRange(u, v) * 1.2;

	if (range > 1) {
		// render shadow
		value.setColor(RGBAColor.black());
		double shadow = Math.pow(2 - range - 0.1, 8);
		value.setAlpha(shadow);
		return;
	}

	// set the base color
	value.setColor(color);

	// add the darker color transform
	value.merge(darkerColor, (v - 0.1) * 1.2);

	// add the inner shadow
	if (range > 0.8) {
		double shadow = (range - 0.8) * 2;
		value.merge(RGBAColor.black(), shadow);
	}

	// finally add the highlight
	double highlightRadius = calculateCircleRange(u, v + 0.05) * 1.5;
	if (highlightRadius < 1) {
		double highlight = v * 2;
		value.merge(highlightColor, Gradient.clip(1 - highlight));
	}
}

This is our final button image which is a round red glass button. However, because this is a procedural texture, we can scale the image in both the u and v directions without loss of quality and we can also create oval buttons. Below you can see a number of different variations.

I’ve also added an enhancement with regards to the inner shadow. Rather than making it a fixed black color, I have used a ColorGradient so the inner shadow transforms from dark to light from the top to the bottom of the button. We did this by adding this private member

private final ColorGradient shadowColor = ColorGradient.buildBlackAndWhite();

and in our inner shadow code, we use this gradient color instead of the fixed black color :

	// add the inner shadow
	if (range > 0.8) {
		double shadow = (range - 0.8) * 2.5;
		value.merge(shadowColor.interpolate((v+0.3)), shadow);
	}

Also, for the last image, instead of using a solid color, I used a ColorGradient from the highlight color to the base color and then the darker color to give it that radial gradient. I plan on writing a generalized version of this texture for inclusion in the next release that will let you set parameters and even pass Texture objects for the main color and the inner shadow.

(Updated 1/19/2009 : Changed links to point to the whole set of articles)
HTML
Single Page HTML
PDF

(Updated 1/19/2009 : Changed links to point to the whole set of articles)
HTML
Single Page HTML
PDF

This first part starts by taking a look at the two frameworks, where they come from and briefly, how they are used.

(Updated 1/19/2009 : Changed links to point to the whole set of articles)
HTML
Single Page HTML
PDF