Skip to content

WTP’s Crazy (and undocumented) Setting Change

12
Oct
2007

I’ve been working recently on a Wicket-based project for a company called Teachscape.  Not only is it based on Wicket, but the project is also designed to be run within Jetty, as opposed to the traditional Tomcat or Glassfish deployment.  This makes local development a lot easier to handle, since you just fire a main-class (which instantiates and starts Jetty) and away you go.  Well, theoretically anyway…

Since it’s a Wicket-based project, all of the HTML files are thrown in with the Java sources and must be on the classpath along with the compiled classes.  The problem is, lately my copy of Eclipse wasn’t doing that properly.  Other Wicket projects on my system (using WTP) still seemed to work fine, but the Jetty-based project just didn’t want to run.  It kept complaining about not being able to find the markup for a specific page.  This is Wicket’s way of telling the developer that they probably forgot a HTML file somewhere.

Now I was able to manually verify that the file did exist in the appropriate directory, named correctly.  It was in an Eclipse source dir which had no exclusion or inclusion rule which would exclude it (either explicitly or implicitly).  In short, it should be on the classpath.  Being savvy to Eclipse’s occasional classpath oddities, I fired a quick clean of the project and tried again.  No luck.  My next step was to do a clean checkout, re-gen the project meta files using Maven, and finally build and run.  Once again, no dice.  This was when I decided to spelunke a bit into the actual build output directory for the project.  When in doubt, check it out by hand, right?

It turns out that none of the HTML files for any of the pages were being copied to the target directory.  I found this more than a little odd, since I knew it was working before and (as I said) none of the source filters should have excluded anything.  So I went in and changed the filters so that only **/*.html files should be included in the build.  The result?  An empty target directory.  Not encouraging.

I tried copying over configurations, editing the .classpath file directly, even looking at the help documentation for JDT, still no luck.  It was the first problem I’ve had with Eclipse in years which I haven’t been able to solve reasonably quickly or work-around.  In short, I was stuck.

Out of sheer desperation, I started browsing through some of the Eclipse JDT and WTP preferences.  I figured that WTP had to have something to do with all of this, since the builder was obviously treating HTML files in a special way and WTP is the only plugin I have installed which might do that.  I came up empty on the WTP front, but when looking through the JDT builder prefs, I found this nugget:

wtp-screwup

What?!  I honestly cannot think of any valid reason why I would want those resources excluded.  WTP doesn’t require it.  After removing these two lines (SVG files probably should be included in the build too), all of my WTP projects still run fine.  In fact, since this preference was obviously added by WTP, it got me thinking: all of this worked fine not two days ago, what happened?

The answer is: I updated WTP.  It seems the latest update of Eclipse WTP adds this preference into your JDT settings whether you want it or not.  Not only that, but there seems to be no warnings, no documentation of any kind which would indicate its purpose or that it even made the change!  I ask you: why was this necessary?

I lost literally hours of time trying to track this down.  Granted, if I was more familiar with the “Output folder” preferences in the JDT compiler settings, maybe I would have figured it out sooner.  But the point is not my less-than-perfect familiarity, the point is that this change seems to require the developer to have advanced knowledge of the Eclipse preference system, just to track down an apparent bug in their own project config.  Bad move, WTP, very bad.

…now that the flames have died down: what is the purpose behind the exclusion of these resources anyway?  If they don’t hurt anything in a WTP project, and they certainly wouldn’t mess with anything in a Java project, why exclude them?  Also, in all fairness I really don’t know for certain that it was WTP that made the change.  I updated the entire Europa train at the same time.  Theoretically, any one of the projects could have made the undesirable modification.  WTP just seemed the most likely since one of the exclusions was *.html, though PDT would be an equally valid guess.

Filed in Eclipse | Comments (4)

Wicket TextileLabel

8
Jul
2007

Well, first I must apologize for not updating my blog in some time. Loads of interesting (and time consuming) things have been happening recently, specifically related to my employment as well as a rather jam-packed holiday week in the US. On a slightly different (but related) note, I resigned from my full time job and am once again “programmer for hire” (if you’re interested, you can drop me an email: djspiewak [AT] gmail). Thankfully, all the closing details seem to be in order, so I’ll finally have a little more time to devote to this blog as well as to writings on EclipseZone.

In that vein I’ve spent a bit more time with Wicket (now Apache Wicket) recently, and I have to confess even more impressed with it than I was a year ago when I first looked at it. The separation of markup and code is a powerful concept that no other framework seems to have achieved to the same level without massive libraries of custom tags. For those of you who aren’t already familiar with Wicket, it’s an Open Source, component-based web framework. You create pages in Wicket by writing a standard HTML file, adding a wicket:id=”yadayada” attribute to the dynamic elements, then you add the corresponding component instances to the Page instance in code. No Java in your HTML, no HTML in your Java.

One of the things I stumbled upon in my latest run at the Wicket is the limitations of its MultiLineLabel component. MultiLineLabel lets you display large blocks of text with the characters appropriately escaped and all line breaks converted to proper <p></p> blocks. It’s not a complicated component, and this is glaringly obvious if you actually need something a bit more substantial.

The site I’m using to experiment has a need for large blocks of (preferably) formatted text. At first, I figured I’d just throw a MultiLineLabel up and call it done. However, the need for formatting seemed a bit more pressing, so I began to look at alternatives. And it occurred to me that perhaps the simplest way to enter formatted text is to use Textile. Unfortunately, this means I need some way to render Textile into HTML within Wicket.

After some Googling, I was able to positively ascertain that there are no Wicket components which provide Textile rendering. Not being one to give up there, I decided to roll my own. After all, one of Wicket’s major selling points is that it makes custom components dead easy, right?

Well, seems the hype is justified in this area too. Although, I must admit the documentation is sorely lacking in this area. I ended up cracking open the source for MultiLineLabel (which was surprisingly readable) and discovering that the key is to override the onComponentTagBody method. With a little more Googling, I found PLextile, which is the most complete Java Textile rendering library. A few minutes of quick hacking later, and I came up with this:

protected void onComponentTagBody(MarkupStream markupStream, ComponentTag openTag) {
    String text = (String) getModel().getObject();
    if (text == null) {
        text = "";
    }
 
    replaceComponentTagBody(markupStream, openTag, postTextilize(new TextParser().parseTextile(text, true)));
}

PLextile handles all the heavy lifting here, and parses out just about everything just fine. It’s main stumbling point is how it handles line breaks. According to Why’s comprehensive Textile reference, line breaks should be handled by wrapping the sections into <p></p> blocks, whereas PLextile was inserting <br/> tags. Quite frustrating, let me tell you.

I considered using RedCloth (Why-the-Lucky-Stiff’s Ruby Textile renderer, wrapped by Rails for the famous textilize method) through JRuby and Java 6 embedded scripting, but it seemed awfully heavy to fire up an entire JRuby interpreter instance just to parse some text, so the decision was made to steer away from that. Instead, I wrote a post-processor for PLextile (hence the postTextilize method in the example above). This method is actually where most of the code is for the component:

private String postTextilize(String textile) {
    textile = "<p>" + textile + "</p>";
    textile = textile.replace("<br />\\r<br />", "</p><p>");
    textile = textile.replace("<br />", "");
 
    return textile;
}

Anyway, wrap it all up into a WebComponent subclass and it’s ready to use in a page. Swap TextileLabel for your former MultiLineLabel usages, and you’re ready to go!

You can download the finished component here.

Filed in Java | Comments (16)