Inspired by a recent discussion about code-generated vs. manual maintained property maker classes, I've come up with an idea which I hope you will find interesting.

The patch I've uploaded


which implement the idea, disables the code generation of the property maker classes and instead creates instances of the base maker types and configures them with setter methods.

        // font-size
        m  = new LengthProperty.Maker(PR_FONT_SIZE);
        m.setInherited(true, false);
        addPropertyMaker("font-size", m);

As a result, the FOPropertyMapping isn't generated anymore but can be maintained as a normal java program.

The two most interesting files can be found here:


I have had to created three handmade maker subclasses to handle the more involved computation of properties:


All the rest of the properties are handled by setting values on the base maker classes which already existed.

I've also removed the enum classes for constants. I don't know if that will be considered a good idea, it just seemed a heavy-weight way of documenting the enumness of the constants. Perhaps it is better to keep the enum interfaces and reuse them to typesafe enums when 1.5 comes along.

Rightfully, this should be slower than having specialized code which just handle the features needed by each maker, but in reality I have not been able to measure any difference. It is however difficult to measure performance while the string->int conversion is taking place.


Reply via email to