Glen Mazza wrote:
-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
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.


Reply via email to