--- Victor Mote <[EMAIL PROTECTED]> wrote: > The current implementation might look like this: > public class FObj { > .... > public int getMaxWidth() { //WARNING > -- unchecked or tested!! > return > properties.get("max-width").getLength().getValue(); > } > > A subclass that doesn't use max-width might override > with: > public int getMaxWidth() { > return FObj.INVALID_PROPERTY; > } >
Not to be a pain here--but this just occurred to me--if we are going to do this, it may be cleaner to rely on enumeration constants--that way, we probably can avoid all these "return FObj.INVALID_PROPERTY" overrides in the various FO's for each unsupported property. This is what I'm thinking (pseudocode here): In FOObj (similar to your code above): public int getProperty(int propVal) { if (validateValidProperty(propVal) == false) { return FObj.INVALID_PROPERTY; } return properties.get("max-width").getLength().getValue(); } Then we may just need a single validateValidProperty() method in each FO, that would check if propVal is an accepted property for that FO. Each FO's validateValidProperty() would not need to degenerate into a huge list of comparisons like this: if (prop_val == PROPVAL1 || prop_val == PROPVAL2 || ... on and on and on) return true; else return false; because I think we can simplify the properties supported by an FO into an integer array of 1's (supported) and 0's (not) so the validate() function for any FO would look like this: validateValidProperty(int propVal) { return (supportedProps[propVal] == 1); } (Come to think of it, we can probably keep validateValidProperty() in the FObj base class alone as well!) Then, finally, we can perhaps expand this array of 1's and 0's to include a 2--"supported by the spec but not yet by FOP", i.e., FObj.NOT_YET_SUPPORTED, and other codes as needed. Comments? Glen __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/