Raible Designs

Westword Music Showcase...

... on a beautiful Saturday afternoon.

.NET's built-in tools and controls generate invalid XHTML and CSS

Mails we've received, forum discussions, and recent Splorp posts all complain that .NET's built-in tools and controls generate invalid XHTML and CSS. The workaround? Don't use the built-in tools and controls. The value of .NET without those built-in tools and controls? Not much.

.NET is Microsoft's platform for web services. It derives it power from XML, a web standard. A product based on one open standard should support others, not break them.

When Microsoft does the wrong thing, developers feel helpless. You are not helpless. You have a choice of development platforms. [Zeldman]

(emphasis mine) The choice is simple, use J2EE ~ where the flexibility is free!

Professional JSP 2.0 Update

Just in case anyone is interested, I thought I'd report on how Professional JSP 2.0 (now being published by Apress) is progressing. I received some initial feedback that my Struts/XDoclet chapter would not be included in the book, but would be a separate download (I'd still get paid for it though). Most of the reasons seemed to be indicating that the chapter was too advanced - newbies wouldn't get it. Personally, I hate reading newbie books, so why would I write a newbie chapter? I also hate simple sample apps, that's why I wrote a fully functional one. Anyway, I convinced them that this chapter did have value and now they are going to include it in the book, but as a case study rather than a regular chapter.

As for the security chapter, they said they really liked the content, but (again) the example was too advanced. I have been asked to remove XDoclet as a dependency since I don't explain it until the Struts chapter. This turned out to be a lot easier than I thought it'd be - only took me about an hour last night. I simply built the project with XDoclet, and then copied the artifacts (web.xml, generated ValidatorForms, struts-config.xml, validation.xml, *.hbm.xml, etc.) back into the source tree. I then tweaked the build.xml file to pick up the artifacts, ran "test-all" and voila - it worked?!

The lesson I learned from all this is that XDoclet is great for rapid development - but possibly only while you you are developing new features. Once an application stabilizes or development is discontinued (I don't plan on further developing security-example), it's pretty easy to strip out the XDoclet dependency and (probably) make it easier for users to understand.

Quit Reading Me!

Just kidding. It's just that the ol' bandwidth issue has reared its ugly head again. I sent the following message to Keith last night:

Am I reading this stats page correctly?

Am I already over my KB limit for the month?

His response:

Wow, you've almost 3/4 million hits already this month....

It looks like it averages about 7.7K per hit, so yep, you appear to be over 5 
GB already this month.

I only have a 5 GB plan, so I asked him how much it would be to move to a 10 GB plan (no response yet). Why don't I just move? Because I like Keith, and ever since I moved to the new server, stability has been awesome. I pay $30/month for the 5 giger, so hopefully I can get the 10 GB for an extra $10/month. Then again, according to this page, 8 GB is $80/month. Maybe I will be moving...

[ANNOUNCE] Commons EL 1.0 Released!

The Jakarta Commons Team is pleased to announce the first official release of Commons EL from the Apache Software Foundation. Commons EL provides an interpreter for the Expression Language that is part of the JavaServer Pages(TM) specification, version 2.0.

For more details see the release notes.

Source and binary distributions are available from the mirrors. Please remember to verify the signatures of the distribution using the keys found on the main apache site when downloading from a mirror.

For more information on Commons EL, see the EL web site.

Hmmm, I wonder if this means we can add EL support to the display tag library without including JSTL?

Using Struts' Declared Exceptions

With a little prodding from Erik Hatcher today, I took another look at Struts' Declared Exceptions feature. At the end of last year, I was wishing I could use declared exceptions to do chained exceptions for my Action classes. Basically, in each of my Actions, I have a try/catch wrapped around a call to the Business Delegate (example: UserAction.java). You'll notice that all the CRUD methods have the same catch block for exception handling:

} catch (Exception e) {
    e.printStackTrace();
    errors.add(ActionErrors.GLOBAL_ERROR,
               new ActionError("errors.general"));

    while (e != null) {
        errors.add(ActionErrors.GLOBAL_ERROR,
                   new ActionError("errors.detail", e.getMessage()));
        e = (Exception) e.getCause();
    }

    saveErrors(request, errors);

    return mapping.getInputForward();
}

After talking with Erik this morning, I decided to create an ActionExceptionHandler for java.lang.Exception. In my struts-config.xml, I added:

<exception type="java.lang.Exception" key="errors.general"
    handler="org.appfuse.webapp.action.ActionExceptionHandler"/>

I have "errors.general=The process did not complete. Details should follow." Here is the code for ActionExceptionHandler:

public final class ActionExceptionHandler extends ExceptionHandler {

    public ActionForward execute(Exception ex, ExceptionConfig ae,
                                 ActionMapping mapping,
                                 ActionForm formInstance,
                                 HttpServletRequest request,
                                 HttpServletResponse response)
      throws ServletException {
        ActionForward forward = null;
        ActionError error = null;
        ActionErrors errors = new ActionErrors();
        String property = null;

        // Build the forward from the exception mapping if it exists
        // or from the form input
        if (ae.getPath() != null) {
            forward = new ActionForward(ae.getPath());
        } else {
            forward = mapping.getInputForward();
        }

        ex.printStackTrace();
        errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(error.getKey()));

        while (ex != null) {
            errors.add(ActionErrors.GLOBAL_ERROR,
                       new ActionError("errors.detail", ex.getMessage()));
            ex = (Exception) ex.getCause();
        }

        // Store the errors and exception
        request.setAttribute(Globals.ERROR_KEY, errors);

        return forward;
    }
}

This allows me to remove my generic try/catches from my action classes - very slick IMO (or at least better than the code smell I had)! Of course, I still have some catch blocks that catch specific exceptions, but I can either (1) leave those intact, or (2) create another declared exception for that particular action/exception. I dig it and will be adding it (in short order) to AppFuse.

Update (June 23, 2003): Here's a more thoroughly tested code sample of this same class.

The Matrix at Red Rocks

This looks pretty cool - they're showing "The Matrix" at at Red Rocks. Not the new one, the old one - which I've been longing to see again ever since I saw Reloaded. For those of you not familiar with Red Rocks, it's an awesome natural ampitheater - and it's only minutes from my house (15 minutes on a bike). I just might have to go - looks like fun.

Sending POJOs to the UI instead of ActionForms

I'm starting to think that my Struts-based apps could be simplified if I didn't convert POJOs to Action Forms when retrieving them from the database. By this, I mean to say that I'd like to retrieve and display POJOs on the UI, and then capture their information (as Action Forms) when saving the form. The reason I want to do this is because of Hibernate's Lazy Loading feature and formatting Dates. Basically, Hibernate allows you to load children of an object lazily (i.e. resumes of a User), when the getResumes() method is called. I've created [a page|POJOsToForms] on my wiki to explain further and continue this discussion. Of course, you can always leave comments here if you'd rather - they cross-reference each other. The [RollingWiki|http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerWikiPlugin] rocks!

www.mail-archive.com

If you're doing development on an open source project, I recommend that you get your mailing list archived by mail-archive.com. It's pretty easy to setup and offers a nice google-like search interface. I recently added struts-apps, struts-menu-user and the display tag lists. I hope this makes it a lot easier for folks using these applications. I might even add Roller, but I figured Dave could handle that if he really wants it (it's already being done by gname anyway).

Either way, gname or mail-archive.com, if you're using a SourceForge mailing list, you'd better get a better archiving system b/c SourceForge's sucks! Why? No searching! What good is an archive without searching?!

JSPWiki's RSS Feed

JSPWiki has a pretty slick RSS Feed. If you subscribe to it, it will show you the diffs for the pages that have changed since you last updated the feed. Now that is cool! All wiki's should have this feature IMO. If you're running JSPWiki, and you don't have an RSS feed, I think it's time to get one (hint, hint).