Abandoning code-generated Property.Maker

[Finn Bock <bc...@worldonline.dk>]

Hi,

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

     http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873

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);
         m.setDefault("12pt");
         m.setPercentBase(LengthBase.INH_FONTSIZE);
         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:

     http://bckfnn-modules.sf.net/FOPropertyMapping.java
     http://bckfnn-modules.sf.net/Property.java

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

     [inline|block]-progression-dimension
     [start|end]-indent
     border-[left|right|top|bottom]-width

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.

regards,
finn