Kiss My App

Tuesday, November 30, 2004

Practice What You Preach

This post is actually part II of my Annotation Inheritance blog. Based on some of recent rants, I'm finally fleshing out my own framework with some of the new features in J2SE 5.

The framework is another MVC framework, but don't leave yet... it's goal is to be completely configureless-- no XML files to manage along side your code. My hope is that when it's finished, I can look at rolling back some of the features into a future addon to JavaServerFaces. Some of the goals I have:

Lightweight constructor-injection factory-- and I don't mean container. The factory has the same goals as Picocontainer, but doesn't manage lifecycles at all at creation. Instead, it uses what's called "wormholing" to provide state and additional developer features like named bindings at higher layers. The way this works is that a company can create their own Container object and provide it an instance of my factory implementation. When a certain type is requested, the container is passed as a parameter, and then used in the construction of the instance. This is the wormhole, where top level objects are passed to the lower level objects in order to allow things such as lifecycle managment or proxying to occur.

The view and navigation should be maintained by the view if possible-- allowing not only form data to be submitted in the post, but also your "action forwards".

Annotation driven configuration. This means that contextual data such as converters or validators are declared right with the property on the object. This allows configuration data to be strongly typed and does not require "runtime" type checking of configuration data. Granted I'm anti-AOP, but I believe this solution runs more in line with straight-talking OOP principals. I can have a User object with all of its properties, then simply create a UserForm that extends User with all of the annotations you want to use for the web framework-- or simply apply them to User itself. The reason why declaring annotations like this is safer than AspectJ, is that the annotations aren't going to affect anyone unless they are specifically looking for them-- a reversal of roles you could say.

An example would be taking something like a "first name" property on a bean and declaring (on the setter) annotations like "@ValidateNotNull" and "@ValidateLength(16)". My hope is to have the validation processors abstract enough that they can be easily used outside of the MVC realm.

The reason why I'm finally posting some of my ideas is that they are now actually working. The generics and annotations in J2SE make everything seem so clean and exact in what you are doing-- no guessing games anymore in trying to make flexible frameworks. After I got home from work, I was able to put together a working example of a validator annotation with pseudo inheritance. Also, I was able to stack various validators on a single method or class in order to work like Common's Validator, but in probably a tiny fraction of the code and without the configuration files.
Here's an example of what a developer would have to add to their POJO "backing" bean for a web form (no implements or extends required).

public class NewUserAction {

protected String firstName;
protected int age;
protected UserDao dao;

public NewUserAction(UserDao dao) {
this.dao = dao;

public String commit() {
dao.add(new User(firstName, age));
return "pass";

public String getFirstName() {
return firstName;

public void setFirstName(String firstName) {
this.firstName = firstName;

public int getAge() {
return age;

public void setAge(int age) {
this.age = age;

Hopefully I will have the framework ready by the end of the year. I was going to post the working validator source code with annotation processing, but I would like to wait and publish an actual framework or article, not just bits and pieces.


Post a Comment

<< Home