RJUG: Tag-team Generics

Event

This month’s presentation at the Rochester Java users Group was a bit of a hoot. Rochester Institute of Technology instructors James Heliotis and Axel T. Schreiner gave a tag-team presentation of Generics for Java and C#. Heliotis channelled James Gosling and Schreiner channelled Anders Heilsberg. Each tried to point out the foibles and flaws of the other’s implementation of Generics. Being both an ASPx and a Java develper, the smack-down code-off was a special treat for me.

Most of the work I do now is centered on Chains of Commands and Contexts, which seem tailor-made for Generics. One of the trade-offs with Commands and Contexts is that you have to do a lot of casting along the way. I’m thinking Generics might alleviate much of the casting.

iBATIS 1-2-3

Event

According to a post on iBATIS dev@, “Lotus would like to use iBatis for Java’s data mapper capabilities in a future release of an IBM / Lotus collaboration product.”

If so, we might see a rising number of iBATIS articles published by DeveloperWorks. As of today, there’s four

 

versus about nine for another popular data access framework.

Ready, Set, …

Meanwhile, rumour has it that iBATIS in Action is now manuscript-complete and in the final stages of peer review. (OK, it’s more than a rumour, I’m one of the peers!)

IIA was a year in the making by none other than Clinton Begin, Brandon Goodin, and Larry Meadors. The book is not available for pre-order yet, but look for it soon. The book is mostly Java focused, but Chapter 1 and Appendix A include some .NET topics. So, there’s yet something for Gilles, Roberto, and Ron to do :)

Tapestry: Rolling toward TLP

Event

Our friends at Tapestry have taken the first step to move out from under the Jakarta umbrella. In an unanimous vote held on Tapestry dev@, the community voted to request that the ASF board install Tapestry as a top-level ASF project.

Of course, being a top-level project makes no practical difference to Tapestry users. It will be same team, same license, and same infrastructure. The difference is that Tapestry now has both more autonomy and more accountability. As a TLP, it would be easier for Tapestry to grow and add subprojects of its own. And, as a TLP, Tapestry will report directly to the board, rather than through the Jakarta Project Management Committee.

Like Struts Action and Struts Shale, Tapestry is an open-source framework for creating dynamic, robust, highly scalable web applications in Java. Tapestry complements and builds upon the standard Java Servlet API, and so it works in any servlet container or application server. Tapestry is a fine framework with a feverent following.

Tapestry is also one of the oldest frameworks for Java. Tapestry 1.0 was released in May 2001, a month before the initial release of Struts. Even then, the Tapestry approach stood out from the other new frameworks. Some say that Tapestry is closer to ASP.NET than frameworks like Struts. The first preview of ASP.NET was unveiled in July 2000, and ASP.NET 1.0 shipped in February 2002. By mid-2001, several Java frameworks were available, including Barracuda, Expresso, Maverick, Struts, and Turbine, among others

While some of these frameworks have faded away, I’m glad to see that, like Struts, our old friend Tapestry is also moving forward, stronger than ever.

WebWork 2.2 - What's in it for me?

Essay 

On 7 Feb 2006, Raghu Kanchustambham wrote on user@struts.apache.org:
> I am using struts 1.2.8 and use the struts-layout
> tags for my UI components. I have done some 50%
> of my project work using this combination. And
> I must say I am quite happy with what these
> layout-tags offer so far.
>
> Now, how do I get webwork into my ecosystem?
> Is it correct that webwork’s main strength is
> its rich UI components?
> Can I make struts-layout (or for that matter
> any other struts based taglibs) to co-exist with
> webwork ? Will integrating with webwork mean that
> if I replace my current struts version with the
> integrated new version, my earlier taglibs will
> stop working?

WebWorks is a very flexible platform, and there is room for creating a 1.x interceptor that mimick the Struts environment so that Struts specific taglibs could work. We could also do things like use XML transformations to migrate configuration files. I believe Don Brown’s been working on some things along those lines. But I think the heads-down work on a compatibility layer will happen after we pass the codebase through the Incubator and can work on it here.

Of course, the web application platform is already open. If you wanted to use WebWork or Action 2 for some things in your current application, you could drop the new JARs into your application and have Action1 handle the .do’s and have Action2 handle the .do2’s.

For new development, the WebWork UI tags already do many of the things that packages like Struts Layout do, and we can continue to extend the UI tags, so that the UI tags better meet all of our needs.

> What does this [WebWork] integration mean
> to a developer like me?

Here’s the bottom line: We could spend the next six years slowly evolving Struts Action 1.x until it ends up looking like a WebWork clone, or we could all work together on creating an even better Action-based framework. Both Struts and WebWorks are already the best in some way, but as Google says: “Never settle for the best.”

Of course, a lot of us have Struts 1.x application in development or in maintainance mode. We’re about to roll Struts Action 1.3.0, and on the dev@ list, people continue to talk abouta Action 1.4, and so on. Which is great! To keep a line of development alive, all we need is volunteers who want it to live.

> In the Microsoft world, good(?),bad,ugly
> - there is just one choice.
> On day 1, you know “this” is what I need
> to use in the MS world!

I’ve been working in ASP.NET for going on two years now. It’s true that if you’re writing simple applications, yes, what they ship in the box is just fine. Just like what Java ships in the box (JSTL and JSF) is just fine.

But, .NET developers writing enterprise applications are reaching for all the same tools we have for J2EE. If you look at the ASP.NET example frameworks, you can see the evolution away from simplistic, monolithic applications and toward rich, layered applications. One example uses this data access library, the next uses another. Same old, same old.

I think the difference is that ASP.NET teams tend to use extra libraries and packages in stealth mode, where J2EE teams wear their extensions on their sleeves. (And, at conventions, on our T shirts!)

I would agree that it’s time that we did more to help enterprise ASP.NET developers come out of the closet and embrace choice. Action 2 for C# and FastCGI anyone?