Matt, RTFM! Commons Collections HAS CLOSURES.

Thanks to everyone who pointed me to Commons Collections and its Functor package yesterday. To me, this is just one step below having closures natively present in the language. FYI, I was able to remove all duplication from my class and reduce the LOC from 211 to 136 - in other words, 75 lines of useless code GONE.

Here is what I did. First, I defined Predicates for each of my conditions. The simplest ones called a boolean method on the User object:

private final Predicate isX = new Predicate() {
public boolean evaluate(Object object) {
return ((User) object).isX();
}
}

Only slightly more complicated ones checked to see if a given Collection was empty on the User object:

private final Predicate isX = new Predicate() {
public boolean evaluate(Object object) {
return CollectionUtils.isNotEmpty(((User) object).getItems());
}
}

Next, I defined a method that would check the delegations for the User to see if any of them were an X:

boolean checkDelegations(User user, Predicate checkPredicate) {
return CollectionUtils.exists(user.getDelegations(), checkPredicate);
}

Finally, I implemented the security methods:

public boolean canDoThis() {
return isX.evaluate(loggedInUser) || checkDelegations(loggedInUser, isX);
}

Maybe it isn’t the most elegant or simplest of solutions, but it sure is a lot better than what I posted yesterday!

P.S. Since this is a Christian blog, I must remind you that RTFM stands for Read The FINE Manual!


Java needs closures

I’m sure everyone is sick of reading this same rant over and over, but I just had to add more fuel to the fire. I’m attempting to implement access privilege delegation in a JSF application - basically, users can delegate their ability to do “stuff” in our application to other users. I have a backing bean that has several methods that are called by the JSF components, returning whether or not to render that component based on security privileges. Well, I now have to make all of those methods aware of delegation! I have something like this in several methods:

boolean notX = (loggedInUser.isX());
if (notX) {
boolean result = false;
Set delegations = loggedInUser.getDelegations();
for (Iterator i = delegations.iterator(); i.hasNext();) {
User delegator = (User) i.next();
if (delegator.isX()) {
result = true;
break;
}
}
return result;
} else {
return true;
}

Now, it would be nice if I could extract the contents of that if block into a new method, say “checkDelegations()”. Unfortunately, the isX() that I need to call is different for every method following this pattern. I’d like to be able to pass a function that calls isX() on the delegator into the checkDelegations() method. No dice in Java. Does anyone else have a solution to this problem?


Raible’s Wiki: AppFuseRoadmap

Raible updated the AppFuseRoadmap yesterday. I’m really excited about where the project is going. XDoclet has been a good friend, but I’m really happy to see its demise in favor of annotations. JDK 5 and JSP 2.0 will also be really helpful - I’ve wanted to leverage these technologies for a long time, but haven’t had an easy way to do so. I think the most interesting thing for me will be the switch over to Maven 2. I have absolutely ZERO experience with Maven, other that seeing the pretty websites that it generates for many of my favorite open source projects. I consider myself to be something of an Ant wizard, so I hope that I’ll be able to leverage that experience in Maven.

It looks like TestNG replacing JUnit is a nice-to-have for 2.0 - I hope this becomes a configuration option. I don’t know anything about TestNG. Perhaps it’s time to learn. :-)

AppFuse 2.2 is where things are really going to start getting cool. Convention over configuration (ala RoR) will really speed development, and features by plugin will make my life really easier. I spend a lot of time stripping things out that I don’t need for particular projects - the time I save by using AppFuse is worth the pain of stripping them out - so this will be yet another way that AppFuse will make Java EE development a pleasure.


It seems that AppFuse has a competitor!

I found Project Able while reading Raible’s blog this morning. While it doesn’t claim to duplicate everything that AppFuse does (i.e. they pick a framework and stick with it instead of providing choice), they are doing some neat things. I may take a look at it if I ever have time. :-)

Project Able is a full Java-based web development stack designed to make web development painless. In a sense, it is an attempt to bring together quality opensource tools in one cohesive stack, similar to what Rails has done for Ruby, while also encouraging common practices I’ve used in software engineering for a long time.

It is very similar to projects such as Trails, Grails, and AppFuse. However, there are a few key differences:

  • The stack components are different (WebWork, Spring, iBatis, etc).
  • In addition to the basic framework, Able also encourages common development techniques and patterns (more below).

Seven simple reasons to use AppFuse

I’ve wanted for some time now to write a blog entry promoting my favorite open source project - AppFuse. Since I started developing web applications using AppFuse as a base, I can truly say that I’ve rediscovered the joy of software development. I’ve found no other technology or methodology that has allowed me to place as much focus as I now do on solving business problems and not on technology ramp-up or figuring out the eccentricities of “framework X.” In this article, Matt Raible, the founder of the AppFuse project, humbly states very compelling reasons that you should use AppFuse for your J2EE development. To summarize, here are the 7 reaons:

  1. Testing
  2. Integration
  3. Automation
  4. Security Features and Extensibility
  5. Code Generation with AppGen
  6. Documentation
  7. Community

Read the article to get the meat:

Seven simple reasons to use AppFuse