Ext JavaScript library

If you're developing a web page/site with JavaScript, you should at least be aware of the Ext JS JavaScript library. Ext functions well as an Ajax library, in addition to a general purpose set of extensions to the JavaScript language and DHTML.

Update (2008-05-03):

Ext JS is suffering a licensing crisis:

• John Resig on ExtJS, the GPL fiasco and open source community style (Stephan Schmidt, 2008-04-28)
• 600+ replies and 55,000+ views on Ext JS's forum thread, License Change?

I'm moving to The Yahoo! User Interface Library (YUI).

Ext's official site is http://extjs.com/. Wikipedia also has an article.

Features

I strongly agree with Bruce Kroeze's review: "Why I'm moving from jQuery to ExtJs". It lists a number of ideals, and Ext meets just about every expectation, where other libraries such as Prototype fall short. Some of these include:

• Respecting the global namespace and base language, without polluting it with numerous function and variable names. (See my Respecting the JavaScript global namespace and JavaScript Closures posts.)
• Performance. (See "CSS Selectors - Speed Myths". Written by the Ext lead developer, so beware of some probable bias.)
• Capable DOM manipulation. (See Ext.Element)
• Capable CSS selectors. (See Ext.DomQuery)
• Capable event listeners / event management. (See Ext.EventManager)

More features as listed from Wikipedia:

• A diverse set of form controls (or "widgets").
• A powerful DOM selector class allowing operations to be performed on elements within the page with a high degree of flexibility.
• Data stores that can be used to contain and manipulate complex sets of data.
• Classes to create and manipulate data in JSON and XML formats.

Demonstrations of many of these features can be seen at the Ext documentation page in the 'Examples and Demonstrations' section.

Issues

While I don't want to discourage anyone from at least trying this capable library, there are a few issues you should at least be aware of:

• Documentation is sometimes a bit over-assuming, especially in terms of initial setup.
  • Viewing the sources of the example pages and searching on the Ext forums are helpful resources.
• A number of the form control / widget features are dependent upon included CSS includes for proper display. Unfortunately, ext-all.css contains the definitions from reset-min.css, which resets almost all margins and paddings to 0, as well as removing a number of other base formatting attributes without providing default alternatives. One consequence of this is that it effectively makes lists and headings appear just as normal text.
  • Jeff Howden of the Ext Support Team posts the following explanation on the Ext forum:
    There are tons of differences in just margin and padding alone on numerous elements between the major browsers. That bit of CSS simply equalizes things. If you have custom CSS styling you wish to apply, simply include that CSS after ext-all.css.
  • See the "ext-all.css defines basic html tags such as p, h1, h2, .." post for the full discussion/explanation.
  • See also the "Sandboxing Ext CSS" forum post.
• The Ext GUI components appear dependent on a given set of font and other formatting options for proper display. Including Ext's ext-all.css file sometimes isn't even enough. Some symptoms I experienced included missing borders under Internet Explorer. See my thread on Ext's user forums for the details.

As for the ext-all.css issue, the best option I've found is to write and include your own "ext-unreset.css" file after the ext-all.css include in your web page. I found referencing the default .css used by Mozilla Firefox to determine some ideal default values is a good start. (Look for res/html.css in your Firefox installation directory.)

Forums

I've made (and probably will continue to make) a number of postings on the Ext user forums that may be of some interest. If you'd like to search for them, my username is "ziesemer". The forum's PHP search action seems a little odd, but this link seems to return a list of my posts: http://extjs.com/forum/search.php?searchuser=ziesemer&do=process.

Scraping Sun's bug database with NekoHTML

Sun has a rather comprehensive bug database at http://bugs.sun.com/, which is probably most notably used to track Java bugs. Unfortunately, at least with the interface and options presented to the general public (such as myself), some aspects are rather lacking. Beyond being able to vote for a bug (only up to 3), and creating a single "watch list", it appears to be a far cry from Bugzilla.

The feature I've been missing the most, however, is an easy way to keep track of bugs of interest, and by extension, being able to share bug lists / searches. Bugzilla makes this incredibly easy by offering a number of export options, including XML, CSV, and RSS feeds. As of Bugzilla 3.0, saved searches can also be shared, as an effort of Bugzilla Bug 69,000, and is demonstrated in Bugzilla's public test environment, http://landfill.bugzilla.org/bugzilla-3.0-branch/.

As a side note, while both https://bugs.eclipse.org/bugs/ and https://bugzilla.mozilla.org/ appear to be running version 3.0+ of Bugzilla, neither currently seem to have these shared queries working/enabled. (I've opened bug 223594 on Eclipse to hopefully address this.)

Java HTML Parsers

Unfortunately, as I previously mentioned, Sun isn't using Bugzilla, and there are no export options of any type. As far as I can tell, this really only leaves parsing the HTML as the only option.

If the HTML returned by Sun on their bug pages was valid XHTML, this would be an easier task. Just write a few XPaths to find the necessary fields, format the data as desired, and another task complete. Unfortunately, the pages are returned simply as regular HTML, not the XML-compatible variety. At least unlike Blogger, Sun's pages are at least returned with a valid identifying type that actually matches the page, in this case a doctype of "-//W3C//DTD HTML 4.01 Transitional//EN".

There are many ways to parse HTML. While I know a lot of people like Perl, I prefer to stick with the Java approach. In any language, there are also many existing tools and frameworks to help with the task, so starting from scratch would probably be a waste of time. The non-XML-based version of HTML can be rather messy, with unbalanced tags, missing escape sequences, and other issues that will quickly lead to headaches - and these tools will help "clean" the input.

I recently found a blog posting about a similar goal: "Showdown - Java HTML Parsing Comparison" (Ben McCann, 2008-02-02, lumidant.com). He demonstrates 4 Java libraries for parsing HTML, including NekoHTML, TagSoup, jTidy, and HTMLCleaner. (Unlike the referenced blog, I've linked these utilities to their official sites for your convenience.) The referenced post favored HTMLCleaner, as it was supposedly the only tool to successfully extract 10/10 documents. I've had better luck with NekoHTML. I'd be curious to see the rest of the code that was used, as I suspect that case sensitivity and a few other issues may have played into the results, and at least with NekoHTML, can easily be normalized with a configuration option or two.

NekoHTML

In the past, I utilized HttpUnit as such a tool. It actually uses NekoHTML as the parser, then provides a HTML-specific API for navigating/querying the "cleaned" document - as well as performing actions, for HttpUnit's real purpose as a testing framework.

Of the four parsers listed above, NekoHTML definately seems to be the most comprehensive and as of recently, actively maintained. After a period without any releases between June 2005 and December 2007, it was relaunched on SourceForge. Beware of version 1.9.6.2, however, as there seems to be a rather severe regression bug with the handling of single quotes, as I reported in issue 1922810.

For starting with NekoHTML, I recommend the following configuration:

import org.cyberneko.html.parsers.DOMParser;
// …
DOMParser domParser = new DOMParser();
domParser.setFeature("http://cyberneko.org/html/features/insert-namespaces", true);
domParser.setProperty("http://cyberneko.org/html/properties/names/elems", "lower");

See http://nekohtml.sourceforge.net/settings.html for the details of these options. The insert-namespaces feature basically utilizes the XHTML namespace, http://www.w3.org/1999/xhtml, to all HTML content, allowing for distinction between HTML content and other possible content defined in an alternate namespace within the document. The names/elems property instructs NekoHTML to convert all tag names to lower case, which matches the XHTML specification (compared to upper-case for HTML). Setting the insert-namespaces feature seems to be a pre-requisite for the names/elems property.

The only down-side to enabling XML namespaces is slightly complicating the use of XPath. In order to properly query elements in XML namespaces with XPath, a javax.xml.namespace.NamespaceContext implementation needs to be registered to the XPath using XPath.setNamespaceContext(…), which maps prefixes to namespaces, etc. (See NamespaceContextMap in MarkUtils-XML.)

Parsing Sun's bug pages

For extracting the fields from one of Sun's bug pages, I formulated two XPath expressions:

//html:table[preceding::html:a[@name='skip2content']]//html:table/html:tbody

This expression finds the body of the table after an anchor that separates the desired content from the rest of the page headers, navigation, etc.

html:tr[html:td//text()=$pageLabel]/html:td[position()=2]

This expression finds the value of a desired field on the page, e.g. "Bug ID:", "Synopsis", or "Category", as currently represented by $pageLabel above. The expression finds the first <td/> node matching the desired label, then returns the following <td/> node that contains the desired value.

Use a XPathVariableResolver to handle the variable in the 2nd expression. If multiple bug pages are to be processed, these expressions should probably be compiled to XPathExpressions for repeated use.

Here is my export of the bugs I'm currently "watching" / am interested in:

Bug ID	Synopsis	Category	Reported Against	Release Fixed	State	Priority	Submit Date
4079882	Request for JTristateCheckbox implementation	java:classes_swing	1.3.1 , 1.4.1 , 1.1fcs		In progress, request for enhancement	4-Low	1997-09-17
4187336	ServletResponse.setContentLength(Long)	javax_servlet:api	1.1fcs		Closed, will not be fixed	4-Low	1998-11-05
4526561	File system change notification events should be supported	java:classes_io	merlin-beta2		In progress, request for enhancement	4-Low	2001-11-13
4652184	please compile j2sdk rt.jar with -g (all options)	java:build	1.4.2 , 1.4.2_04 , merlin-rc1 , tiger-beta , tiger-beta2	mustang(b28)	Closed, fixed	4-Low	2002-03-13
4782054	Allow for comments in the MANIFEST.MF file	java:jar	1.4.1		In progress, request for enhancement	4-Low	2002-11-20
4787931	System property "user.home" does not correspond to "USERPROFILE" (win)	java:classes_lang	1.3 , 1.4.1 , 1.4.2		In progress, bug	3-Medium	2002-12-03
4838318	(str) Substitute CharSequence for String arguments wherever possible	java:classes_lang	1.4.1 , 1.4.2		In progress, request for enhancement	4-Low	2003-03-27
4880234	ServiceUI needs a printDialog method wtih a Component parameter	java:classes_2d	1.4.1		In progress, request for enhancement	4-Low	2003-06-18
4983159	Typedef (alias)	java:specification	tiger-beta		In progress, request for enhancement	4-Low	2004-01-24
5018574	Unable to set focus to another component in JOptionPane	java:classes_swing	tiger		In progress, bug	3-Medium	2004-03-23
5043696	StringReader should be allow a String{Buffer,Builder} to be the backing store	java:classes_io	1.4.2		In progress, request for enhancement	4-Low	2004-05-07
5096679	PIT:PrintDialog is not positioned properly on multi-mon, when coords are invalid	java:classes_2d	mustang		In progress, bug	4-Low	2004-09-03
5109347	PrinterJob.printDialog() does not support multi-mon, always displayed on primary	java:classes_2d	1.4		In progress, bug	4-Low	2004-09-30
6192554	Need generic factory interface.	java:classes_util			In progress, request for enhancement	4-Low	2004-11-09
6212751	DOC: ServiceUI.printDialog() need to enhance the description for X,Y coordinates	java:classes_2d	1.4		In progress, bug	4-Low	2004-12-27
6214380	Quality setting is disabled and always set to Normal in Print Dialog	java:classes_2d			In progress, request for enhancement	4-Low	2005-01-05
6215174	Can't force layout of non-showing component	java:classes_awt	5.0		In progress, request for enhancement	4-Low	2005-01-07
6312085	The for/in statement should support Iterators	java:specification	tiger-beta		In progress, request for enhancement	4-Low	2005-08-17
6325564	(str) Provide CharSequenceReader with sub-sequence capability	java:classes_lang			In progress, request for enhancement	4-Low	2005-09-19
6358852	Add methods on concurrent data structures that interrupt blocked threads	java:classes_util_concurrent			In progress, request for enhancement	4-Low	2005-12-05
6400189	raw types and inference	java:compiler			In progress, bug	4-Low	2006-03-17
6476646	(str) Make AbstractStringBuilder class public	java:classes_lang			In progress, request for enhancement	5-Very Low	2006-09-29

If I can find the time, a complete sample code download may also follow.

Facelets and XSD-converted TLDs for Eclipse

JavaServer Faces builds on JSPs with the goal of simplifying the building of user interfaces. Facelets aims for further improvement by extending JavaServer Faces, but uses XHTML to define the views, removing the dependency on JSPs and some of the associated issues.

There is a very informative review of Facelets on IBM developerWorks, "Facelets fits JSF like a glove" (Richard Hightower, 2006-02-21). Unfortunately, Richard is currently quite correct in that "IDE support for Facelets is minimal".

Why Facelets works differently in your IDE

The biggest shortcoming I see is that when using JSPs with or without Faces, many IDEs including Eclipse use the same Tag Library Descriptors (TLDs) that are used by the JSP container. While the JSP container uses these files for validation, the IDEs use the information to provide syntax and code completion, as well as pop-up documentation for tags and attributes. Since Facelets uses XHTML files for the views instead of JSPs, at least in Eclipse, the IDE support is lost.

Part of the lost support is due to the fact that instead of declaring tag libraries with a special taglib declaration as in JSP, they are instead declared as XML namespaces, as described in the Facelets documentation. Additionally, since the views seem to be more XML than HTML, an IDE's XML editor seems to be a much better pick than an HTML/JSP editor, which may initially seem to be an odd move.

The benefit of an XML editor, such as the one available with Eclipse and Eclipse-based products, is that XML features similar to to the previous HTML and JSP features are available, including content assist and pop-up documentation. However, this is largely dependent on having a valid XML Schema (XSD) - and all Faces provides are TLDs.

The outline to a solution

I then realized that a TLD file is just XML. There is even a complete XSD for TLD files. Why not write an XSLT to convert the desired TLDs into XSDs? Surprisingly, expecting that someone else would have already done this, I was unable to find any such accomplishments. I then wrote my own transformation, and am making my solution available here for your use on http://ziesemer.dev.java.net: facelets-xsd.jar.

Included in this .jar file is:

• My TaglibToXSD.xslt XSL transformation.
• XSD versions of the latest Faces TLDs (html_basic.tld and jsf_core.tld from Sun's Reference Implementation (RI), Mojarra (1.2._08), transformed using the above XSLT.
• A manually written facelets.xsd file, representing the "UI" components from the "http://java.sun.com/jsf/facelets" namespace, as described in the Facelets developer docs. (Note that I was unable to find a TLD, XSD, or any other form of compiled documentation for these tags outside of the linked referenced documentation.)

Note that in at least the Eclipse-based IDEs, the built-in documentation support for XML does not seem as rich as the support provided for JavaDocs. HTML tags are stripped, leaving only the raw text, compared to having rendered/formatted HTML with the JavaDocs. Additionally, Eclipse doesn't appear to provide any ability to expand the displayed documentation beyond the relatively-small pop-up window, and without even any scrollbars, there is currently no easy way to view the complete text in longer descriptions. (The JavaDoc viewer provides an F2 option to expand the view.) As such, I recommend that you keep the HTML versions of the documentation handy: Faces and Facelets.

Configuring Eclipse

While these XSDs should work with practically any IDE or other XML editor that supports XSD, here I'm going to focus on Eclipse 3.3.

(Note that "Eclipse Classic" does not come bundled with the XML editor, though it can be easily installed through the Update Manager. The "Eclipse IDE for Java Developers" does come bundled with the XML editor. Also be certain to use a recent version of the Java JRE to run Eclipse (1.5 or higher), otherwise the XML features will appear to be missing.)

Eclipse comes with a nice feature called the XML Catalog. (See also the wiki page.) In summary, the catalog allows Eclipse to automatically associate a schema or DTD with any open XML document, whether or not a valid or accessible schema location is provided within the XML. This is what I used to have Eclipse associate my generated XSD files with my Faces files. It can even reference the files inside my provided .jar file without the need to extract them.

There are 3 XSDs that can be linked from my provided .jar file, as shown in the table below. Just replace <folder> with the location where you have the .jar file saved, and use forward-slashes (/) for the path. View Eclipse's default entries for examples. Alternatively, you can extract and link to the extracted files, which will also allow Eclipse to automatically populate the Key field. (For more detailed step-by-step type instructions, refer to the referenced links above.)

Location	Namespace Key
jar:file:<folder>!/html_basic.xsd	http://java.sun.com/jsf/html
jar:file:<folder>!/jsf_core.xsd	http://java.sun.com/jsf/core
jar:file:<folder>!/facelets.xsd	http://java.sun.com/jsf/facelets

If you were to store your Facelets views as *.xml files, this should be it. However, *.xhtml is a probably the most common, and a content type should be configured for it within Eclipse. (Without it, the XML features won't work properly, even when a file is opened with the XML editor.)

1. Choose Window, Preferences.
2. From the outline at the left, expand General, click Content Types.
3. From the upper window pane at the right, expand Text, then select XML.
4. From the lower pane, click Add, enter *.xhtml, click OK, then OK again.

You may then wish to make the XML editor the default for *.xhtml files:

1. Choose Window, Preferences (again).
2. From the outline at the left, expand General, Editors, then click File Associations.
3. From the upper window pane at the right, select *.xhtml.
4. From the lower pane, select "XML Editor", click Default, then OK.

The last option to note is when the XML editor is open, "Turn Grammar Constraints On/Off" from the XML menu. (This is described in more detail in the Eclipse Help.) As XHTML (and the TLDs/XSDs) aren't configured to allow "unknown" children, this option usually works best when turned Off, allowing content assist to provide completion options even when the parent schema doesn't allow it (an issue that is outside the scope of this post).

Referencing Java's "Erased" Generics

After digging into EJB 3.0 over the past few days, particularly the Java Persistence API (JPA), I encountered a curious feature in regards to Java's Generics.

From the JavaDocs for @OneToMany:

Defines a many-valued association with one-to-many multiplicity.

If the collection is defined using generics to specify the element type, the associated target entity type need not be specified; otherwise the target entity class must be specified.

Essentially, this means that the JPA implementation must be able to use the genericized type to obtain the target entity class. I never really considered this in detail before, but just assumed that such information was lost at runtime, due to type erasure.

In fact, while the genericized types are converted to raw types, the generics information is still available through reflection.

Here is the (correct and) extended example given in the JavaDoc for @OneToMany: (The referenced page doesn't currently show the generics tags due to an HTML error!)

import java.util.Set;
import javax.persistence.OneToMany;

public class Customer{

  protected Set<Order> orders;

  @OneToMany(cascade=ALL, mappedBy="customer")
  public Set<Order> getOrders() { return orders; }
  public void setOrders(Set<Order> orders) { this.orders = orders; }
}

And here is some sample code to find the "type" of Set at runtime. Given the above example, it should return Orders.class:

import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

public Class getEntityClass(){
  Class<Customer> cc = Customer.class;
  Method m = cc.getMethod("getOrders");
  Type t = m.getGenericReturnType();
  if(t instanceof ParameterizedType){
    ParameterizedType pt = (ParameterizedType)t;
    Type[] ata = pt.getActualTypeArguments();
    if(ata.length == 1){
      return (Class)ata[0];
    }
  }
  throw new Error("Unable to determine entity class.");
}

As the above example works for finding the genericized type of a method, two methods on Class that may be helpful for finding generics defined at the Class level are getGenericSuperclass() and getGenericInterfaces().

Sun's version of "640k": 2GB ServletResponse Content-Length

Whether or not Bill Gates ever actually said that 640k should be enough for everyone, Sun certainly seems to have recreated their own version with javax.servlet.ServletResponse.

I was working on a custom Java servlet to return files out of a zip file stored on a web server (ZipServlet), was trying to implement RFC 2616 as completely and accurately as possible, and noticed an issue with the setContentLength(int len) method. Java's int data type is 32 bits, and all Java data types are signed, meaning that this imposes a maximum declared response length of 2,147,483,647 bytes, or 2 GB.

To be fair, this was probably generous back in 1998. I believe the first 2GB+ file I ever downloaded was a Linux installation DVD .iso, and even today, this type of use is still probably a bit out-of-place for a Java Servlet.

What makes this interesting is the number of other Java classes that already utilize longs (64-bit signed) over ints. java.io.File and java.util.zip.ZipEntry are two examples that come to mind.

I did find a bug entry on this issue, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4187336, opened in 1998. The evaluator's comment is a bit discouraging. I understand the need to maintain API compatibility, but this didn't seem to prevent Sun from fixing a similar bug elsewhere. (I recalled - but am now unable to locate - another java.* class with 2 methods something like int getLength() and long getLongLength(), the later having been introduced later to overcome the size limitation of an int.)

Fortunately, I did find one possible work-around:

javax.servlet.http.HttpServletResponse response;
long length;
…
if(length <= Integer.MAX_VALUE){
  response.setContentLength((int)length);
}else{
  response.addHeader("Content-Length", Long.toString(length));
}

Unfortunately, it probably only serves as informational to the client. The servlet container probably won't make use of this, and resort to sending the content as chunked.

Avoid U-Haul for banning the Ford Explorer

U-Haul definitely seems to know how to upset their customers. Being the owner of a Ford Explorer, I'm unfortunately targeted by one of their seemingly insane business practices. And that's only one of their issues...

U-Haul's ban of the Ford Explorer

I purchased my 2002 Ford Explorer back in 2002. I could go into details, but while I have nothing against other vehicle makes and models, the Ford Explorer seemed to fit my needs.

After graduation, I planned on renting a U-Haul for my move to Wausau, WI. After a round of scheduling and reservation issues which seem to plague U-Haul, instead of picking up my reserved trailer at a mechanic 10 minutes away, I had to drive an hour into Appleton for a place that had a trailer available. Only once I arrived was a told that they could not rent to me, as my Ford Explorer was a prohibited vehicle for trailer rental.

The "U-Haul rejects Explorers" article on USATODAY.com is probably the most informative I've seen. This ban is also described briefly on U-Haul's Wikipedia page, with additional information on 2,500+ pages as returned by a Google search. One of my favorites is http://www.michaelworth.com/loser_uhaul.shtml.

I can understand and even support vehicle restrictions. However, this ban is insanely broad, as it covers all Ford Explorers, even though:

• As shown on Wikipedia, the Explorer was comprehensively redesigned in 2002, including a wider wheelbase and a new suspension.
• While one of the primary drivers for the ban may have been the Explorer's history of rollovers, this was almost completely due to the Firestone tires and improper tire inflations, and limited to model years prior to 2002. My Explorer was purchased in 2002 (after the redesign), with Michelin tires, and receives proper maintenance.
• The Mercury Mountaineer and Lincoln Aviator mechanically identical to the Ford Explorer, just marketed differently with different styles and add-ons. Yet, no Mountaineers nor Aviators are subject to this ban, even the troubled pre-2002 model years!
• If U-Haul is going to be responsible for permitting and banning rentals based on vehicle model, doesn't/shouldn't this only make them more liable if/when a problem does occur on a "permitted" vehicle?

Added to the frustration is trying to make any intelligent communication with U-Haul company. Any rental location understandably redirects related inquiries/complaints to their district manager. However, the district managers state that their hands are tied by the corporate office. Apparently there is no one at the corporate office to address inquiries to, and any attempts are redirected back to the district managers. I've tried sending a few emails, which are simply returned as a generic form-response.

Additionally, it appears that even a model 2008 Ford Explorer purchased today will fall victim to this ban. However, any Ford salesperson I ask about this at least claims to be taken by surprise and completely ignorant to the ban. Thinking that maybe Ford's corporate office would be more concerned, they at least admit to being aware of the ban, but only state that there are no safety concerns with the Explorer, and that they must respect U-Haul's decision. I still think they could do more to stand behind one of their best-selling vehicles as well as to support their consumers.

Fortunately, the recent purchase of our own utility trailer has hopefully eliminated the need for most situations that would otherwise require a trailer rental.

Craftsman Fold-Up Utility Trailer

(While all my previous posts have been somewhat technical in nature, this post may seem out-of-place for some. Only time will tell if this is a one-time occurrence, or if other such posts will follow in the future. I considered starting a 2nd, non-technical blog, but wanted to avoid a possible unnecessary split. Additionally, some posts could belong to both... If you'd like to limit your viewing to one or more topics, please consider making use of the labels.)

The Need

Since Sarah & I bought our first house almost a year ago, our parents were placing bets that we'd end up buying a trailer in less than a year. As they usually are, they were right.

My Ford Explorer has pretty good cargo capacity. A few of the larger items we've hauled home include a lawn mower, grill, snow blower, dishwasher, and various pieces of furniture. However, some of those items pretty much reach the limits. Especially with the amount of renovations we've been doing to the house, there's been several times where we needed a way to haul home larger pieces of construction materials, e.g. 4x8 sheets of plywood and drywall.

One of the main reasons we bought a house in Rothschild (e.g. compared to the City of Wausau) was for one of the lower tax rates in the area. However, this lower rate is reflected in some services. For example, while some other areas may have weekly leaf and yard waste pickups, Rothschild only schedules one near the end of the fall - and the leaves may not even all be off the trees yet.

Last year, one of our neighbors was kind to let us borrow their trailer a few times, but that doesn't always seem the most proper or convenient. Renting a trailer may have been an occasional option, but it definitely wouldn't be convenient, and could become rather pricey rather quickly. Additionally, in a rant that will become a post of its own, U-Haul pretty much has a monopoly on the trailer market, and due to an absurd policy against Ford Explorer owners, I can't rent one!

The Decisions

Some of my good friends back in Green Lake have been extremely kind to lend us their utility trailer (either a 6x10 or 6x12?) multiple times for various moves, etc. I always thought it'd be nice to have my own, but even with our current house, don't exactly have the place to store one. While there would be room on the side of our house, next to the garage, and while the previous owners did store a trailer there, it is technically against ordinance in the Village of Rothschild. (This seems a bit ironic, considering the need to haul yard waste, and since the village doesn't do more pick-ups...)

Even if we did store a trailer there, it certainly wouldn't be ideal. Even as we went shopping, we repeatedly noticed a common theme at just about any place in the area selling trailers: Trailers sitting in the snow, and rusting.

We considered a covered trailer, which would be nice for moving items more delicate or requiring protection from the elements. A covered trailer would also probably be a bit more resistant to outside storage. However, I can see that it could also be a bit more of an "eye-sore", as well as being more expensive, and being an over-kill for our typical needs. For anything we would've preferred a covered trailer for, we can probably make work with a regular utility trailer - just with some additional tarps and tie-downs.

The Winner

A year or two ago, I recall walking through Sears, and seeing a fold-up utility trailer in one of the isles within the store. I didn't think much of it at the time, or regarded it as more of a "toy". However, with all of the above considerations, when Sarah & I made the decision to go out trailer shopping, our goal was to find a different trailer or a reason to not get the one at Sears. Sears still won.

See Sears' product page: "Craftsman Fold-Up Utility Trailer" (item# 07124201000, Mfr. model# 0220). It retails for $1,499.99, but we got a rather good deal on one and paid considerably less.

Before we left for shopping, one thing that was really convincing us to go with this trailer was one of the several great product reviews posted on the Sears product page. The review posted 2007-10-09 by an anonymous reviewer in Camden, PA seemed to match our criteria exactly:

"With Winter vastly approaching, I am so happy that my Craftsman Fold-Up Trailer will not get ruined in the rain and snow. I don't use my trailer much during the fall/winter months because of the weather, so having a trailer that I can roll into my garage and keep out of the elements is brilliant! And when Spring arrives my trailer will be in perfect condition ready for the first trip with the leaves to the dump."

I have to say, especially with the Sears in Wausau being "stuck" in the Wausau Center Mall, I've been repeatedly impressed by their ability to seemingly hold a considerable inventory. Compared to the apparently larger Menards, Home Depot, and Fleet Farm stores in Wausau, Sears seems to be able to have items available on-hand when the others don't. (Having a selection of snowblowers in-stock during one of our earlier snow-storms when everyone else was sold-out was a prime example - and I'm sure the one we purchased was the one we would've purchased even if everyone else still had their full line-ups available.)

Having purchased this trailer and already used it twice, I'm also very impressed with it. We've already hauled home several 4x8 sheets of plywood and drywall. Nothing about it feels weak or "cheap". Even without cleaning up our garage first, it easily fit in our 2-car garage along with both vehicles. The only thing I'm considering adding is a jack to the tounge. I also should get a different trailer hitch for my vehicle for better balance by lowering the front of the trailer by 5-6".

Additional Specs

I've already been asked by several people for some additional specifications on the trailer, since those listed on Sears' product page aren't too comprehensive.

• Requires a 2" ball hitch.
• G.V.W.R: 1500 LB
• Tires: 5.30-12
• Height of trailer when folded and level: 52"
• Height of bottom of trailer bed from ground: 14"

One thing that I thought would be nice would be a wheeled tongue jack. I was going to buy and put one on for $20, but found that when the trailer is folded, there is only about 2" of clearance on the sides of the tongue - not quite enough room for a side-mounted jack. (The tongue actually retracts into the trailer as it folds - rather neat, as it requires less space for storage.) I saw another bottom-mounted folding wheel that may still work, though it isn't a jack.