Note: I added a page to the wiki for this thread.

After thinking about the proposal, I'm not sure it solves anything. 

There are two aspects to the redesign of Property handling in FOP.

      * Interface means the external points of contact for Property data
      * Interface determines impact of changes on other components of
        the system.
      * Implementation means the internal construction of classes 
      * Implementation determines performance characteristics of the

The discussion favours the proposal.

The current proposal asks that FOP will employ Java-Bean-like accessors
for the properties of Formatting Objects visible to the FOTree. As an

 getMaxWidth?() for the property "max-width" 

There are between 250 and 380 of these methods required and they could
be generated automatically from an XML-based list of properties. This
list could be derived (if not generated) from the XSL-FO Specification
itself. Some kind of simple adapter class can be used to equate the
proposed interface to the existing one:

 class PropertyAdapter? extends Property{ // Ugh! just f'rinstance

  // repeat the following about 380 times:
  final public Property getMaxWidth?() { // use final to inline and annoy
    return get("max-width");

There is no statement defining the current interface. This will be
determined from existing code.

The proposal makes no suggestion for implementation and my earlier
submission is not relevant except as an indication that this issue is
linked to performance.


Reply via email to