-1. I'd like to hold off on this, at least until I can gain a better understanding of the autogenerated code. I may still to the same conclusion as the other committers, but Finn's endorsement of the XSLT--as well as the long work of those like Keiron who have worked with the XSLT files--suggests that there are significant time benefits to using them. (At work, I use "SQL to write SQL" all the time, and love the time efficiencies that result.)
Well, the XSLT generation of the Java classes was good for bootstrap, because the properties were gained from the XML source of the spec. The FO java classes were bootstrapped this way too. This came handy while the spec was in flux and properties and elements were added and changed. Remember, FOP tracked the spec from the early development, and some bugs like the white-space-collapse peciliarities are leftovers from this phase.
Unfortunately, meanwhile generating has become more of a burden, because if you look at in in detail, there are very, very few properties which are handled identically. Catering for the fine differences has led to many ugly hooks in the presumably generic code (have a look at GenericShorthandParser, which isn't generic enough to parse font shorthand properties).
[Actually, I'm looking forward to studying the XSLT that generates these files--as I mentioned to Clay that CVS and Ant were two of the initial benefits you get by working on FOP, apparently being about to write Java code using XSLT is a third one...i.e., Yeehaw!, as I believe he had put it... ;)]
Well, I fell for the trap too...I'm all in for code generators, and I regularly use some and write some for myself. However, code generation has to have benefits, and if I have to provide 183 choose cases for individual code for (a fixed number of) 185 items, there is no longer any reasonable benefit. A class hierarchy, and some proper abstractions should be enough to avoid code duplication.
If I had time I'd even rewrite the propery code nearly from scratch, because - provide a proper property expression tree - deal with shorthands and font family selections in a less convoluted way - perhaps use a grammar driven parser for property expressions The intermingling of (improper) tokenizing, top-down parsing and error handling for property expressions as well as the improper reuse of tokenizing for shorthand parsing (despite it being a completely different grammar) was always enough to drive my blood pressure through the roof.
J.Pietschmann
