--- 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/
