Non-applicable properties? (was: ClassCastException when using Table Cells in FOP 0.95B)

[Andreas Delmelle <an...@telenet.be>]

>----- Oorspronkelijk bericht -----
>Van: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
>Verzonden: vrijdag, juni 13, 2008 01:18 PM
>
>>----- Oorspronkelijk bericht -----
>>Van: Vincent Hennebert [mailto:vincent.hennebert@anyware-tech.com]
>>Verzonden: vrijdag, juni 13, 2008 12:17 PM
>>
><snip />
>>
>>FOP lacks of robustness here since it crashes instead of just giving
>>a warning that column-number doesn’t apply to fo:block. Can you please
>>create a bug report on Bugzilla, attaching a complete FO file containing
>>your snippet above as an example?
>>https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop
>>
>>This will help us to keep track of the issue. Thanks!
>
>This is a very easy fix. I'll see if I can take care of it ASAP. I just checked the SVN 
> history of the related source file, and apparently, I had initially added such a check 
> in the wrong place (ColumnNumberPropertyMaker.make(PropertyList), which is
> normally only called to 'make' implicit values; removed in the meantime). 
> The check should still be made, however, in make(PropertyList, String, FObj), so 
> that it is instead called when making the property off an explicitly specified value.

In the meantime, I made this change locally, but stumbled on the fact that we do not have an event defined for non-applicable properties.

Now I'm wondering whether we should warn about those at all. According to the XSL-FO Recommendation, any property may be specified on any FO. If the property is inherited, warning about its being non-applicable is more a nuisance than a feature. I, for one, would rather not get a warning each and every time I define the standard font-size on the fo:root, for example.
That would leave the non-inheritable properties, but there we also have the possibility of specifying the property on an ancestor (to which it does not apply), and then retrieve the value on one of the descendants using from-nearest-specified().
Since we can't check for the use of that function at the time the property is constructed, I'd be inclined to leave the code virtually unaltered. 
The only modification would be:
* surrounding the method body of ColumnNumberPropertyMaker.make(PropertyList, String, FObj) with a check for the type of FO for which the property is being constructed. If that isn't a table-cell or a table-column, then we /silently/ ignore it (after all, it's always possible that the value is referred to further down the stream)
* if it is not a table-cell or table-column, return a zero value to avoid the property subsystem calling make(PropertyList) to construct a default/initial value

If a user does supply a non-applicable property, this is not an error. He may scratch his head for while, trying to figure out why it doesn't work, but I don't think we can expect FOP to cater for /every/ possible mistake... In this case, all it takes is one look at the property definition (*) to find out that the behavior is only defined for fo:table-cell and fo:table-column.


WDYT?


Cheers

Andreas

Re: Non-applicable properties? (was: ClassCastException when using Table Cells in FOP 0.95B)

[Vincent Hennebert <vi...@anyware-tech.com>]

Chris, Andreas,

You’re both right of course. I didn’t have that possibility in mind when
writing my post to fop-dev. No warning needed indeed :-)


> Andreas Delmelle wrote:
<snip/>
>> The only modification would be:
>> * surrounding the method body of
>> ColumnNumberPropertyMaker.make(PropertyList, String, FObj) with a
>> check for the type of FO for which the property is being constructed.
>> If that isn't a table-cell or a table-column, then we /silently/
>> ignore it (after all, it's always possible that the value is referred
>> to further down the stream)
>> * if it is not a table-cell or table-column, return a zero value to
>> avoid the property subsystem calling make(PropertyList) to construct a
>> default/initial value

That’s not so simple IMO. column-number must be assigned its specified
value even when the object isn’t a table-cell nor a table-column.
Simply, no check for column availability must be performed.

<snip/>

Vincent


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Re: Non-applicable properties? (was: ClassCastException when using Table Cells in FOP 0.95B)

[Chris Bowditch <bo...@hotmail.com>]

Andreas Delmelle wrote:

<snip/>

> In the meantime, I made this change locally, but stumbled on the fact that we do not have an event defined for non-applicable properties.
> 
> Now I'm wondering whether we should warn about those at all. According to the XSL-FO Recommendation, any property may be specified on any FO. If the property is inherited, warning about its being non-applicable is more a nuisance than a feature. I, for one, would rather not get a warning each and every time I define the standard font-size on the fo:root, for example.
> That would leave the non-inheritable properties, but there we also have the possibility of specifying the property on an ancestor (to which it does not apply), and then retrieve the value on one of the descendants using from-nearest-specified().
> Since we can't check for the use of that function at the time the property is constructed, I'd be inclined to leave the code virtually unaltered. 
> The only modification would be:
> * surrounding the method body of ColumnNumberPropertyMaker.make(PropertyList, String, FObj) with a check for the type of FO for which the property is being constructed. If that isn't a table-cell or a table-column, then we /silently/ ignore it (after all, it's always possible that the value is referred to further down the stream)
> * if it is not a table-cell or table-column, return a zero value to avoid the property subsystem calling make(PropertyList) to construct a default/initial value
> 
> If a user does supply a non-applicable property, this is not an error. He may scratch his head for while, trying to figure out why it doesn't work, but I don't think we can expect FOP to cater for /every/ possible mistake... In this case, all it takes is one look at the property definition (*) to find out that the behavior is only defined for fo:table-cell and fo:table-column.

+1. I totally agree with your assessment. We don't want lots of warnings 
generated by font-family on fo:root or similar. The same is true for non 
inheritable properties as they may be used by functions like you said.

We need to silently ignore column-number on non-applicable FOs to avoid 
NPE or similar errors during layout. The only other alternative is to 
make layout more robust, but that is a more difficult solution. Also it 
doesn't feel the right place to solve this proble, it should be dealt 
with in the properties package.

Thanks,

Chris