Glen Mazza wrote:
> Sent: Wednesday, November 26, 2003 3:17 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [VOTE] Properties API
>
>
> --- 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!)
IOW (I assume) use a 2-dimensional array, the first dimenension representing
the Object, the second dimension representing the list of possible
Properties.
> 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?
This would again be one of the implementation details that I am trying to
hide, but yes, it makes sense to me, at least as one of several
possibilities.
Victor Mote
