I attended the Boulder Frameworks meeting tonight on WebWork, followed by the Boulder JUG meeting. The WebWork (a.k.a. WW) presentation had a mere 5 attendees, but Kris gave a very good overview of WW and showed how simple it was. Here are some of the strengths of WW according to Kris:
- It's not dependent on J2EE. Many method signatures are empty and it uses interfaces everywhere, rather than parent classes. Sounds cool. Kris likes it because "it gives you a warm fuzzy feeling you're not tied to WW."
- It's not Jakarta. "Jakarta is like a Ketchup bottle - you have to beat it to get anything out of it." I don't know that the WW team produces software much faster than Jakarta though...
- Instead of using the HttpServletRequest, WW uses a Stack, which is essentially the same thing (sans J2EE).
- WebWork has Interceptors. They're like Filters, but WW comes with built-in Interceptors that can be applied declaratively. Kris mentioned there's little documentation on the built-in Interceptors - a wiki page would be nice.
- Action packaging - you can turn a portion of your WW application into a jar and it can be added to another WW application. It sounds good, but I can't think of a use for it right now. Sounds like modules in Struts.
Kris's biggest reasons for liking WW was Interceptors and Inversion of Control. However, Struts has those too. Good presentation. I plan to learn WW and give up this whole my framework is better than yours stance. In fact, I hope to do this with many of the technologies I use everyday. I'm going to start using Orion and Resin so I know if Tomcat really is better, or better yet - when should I use one appserver or the other. I'm learning IDEA so I know when to use Eclipse and when to use IDEA. Today I discovered how IDEA warns me about invalid Javadocs (very nice feature). Eclipse continues to rule the CVS integration world, and I see no reason to quit using it and bitch about IDEA's lack of CVS integration.
After WW, I walked across the hall to listen to James Duncan Davidson talk about "James Driven Development" (my phrase) - also known as Objective Object Orientation. Rather than bore you with the details, here are the highlights:
- Don't abstract too much - just enough to fit your needs. Examples of too much abstraction can be found in Apache's Repositories (James's words - he didn't specify any projects).
- Don't extend, instead create objects do something, then you don't need to know the interworkings of the object.
- Dynamically typed languages rock (i.e. Smalltalk, Ruby, Python). They're much easier to develop with, especially when backed my TDD. You can accomplish similar things in Java using lots of casting.
- He can't wait until something comes along and kills Ant and Tomcat - he never thought they'd make it this far - especially considering he wrote them when he was a Junior Programmer for Sun. He gave Tomcat its name because he thought it'd be good animal on the book cover of an O'Reilly book. He never thought it would happen, and now that it does have a book, he said he's disappointed it's not an actual Tomcat (apparently it's a snow leopard?).
His point about Ant and Tomcat is that 1) something better than Ant will rock, so we should all be happy when something better comes along and 2) Tomcat was never designed (or tested) to be used in the environments its being used in (i.e. Nuclear Facilities). Good stuff - brain is full.
Filip Hanik has provided a nice Ant script for pre-compiling JSPs. Its designed to be run after you've deployed your application to Tomcat. On my current project, it took 1 minute 30 seconds to compile all our JSPs - making it a candidate for new QA and Production deployments only. I'll be adding this to AppFuse's next release and verifying it actually works before I release. I know the compile works, but I want to make sure that my .java and .class files aren't rebuilt the first time I hit a JSP (I've seen this before). Also, you might want to checkout my issues if you run into problems.
Update: I've verified that this really does work - Sweet!
