Traits

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

Fop Devs,

one thing I did notice was a small deficiency in Area.getTraitAsInteger(). 
If the Trait hasnt been set, i.e. the call to getTrait returns null, then an 
exception gets thrown. When Padding is present it is perfectly valid as an 
Integer, so the method should NOT throw an exception saying it isnt an 
integer, when in fact it just isnt present (for that block) Instead it 
should return 0. I have submitted a patch for this.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24705

Chris

_________________________________________________________________
Use MSN Messenger to send music and pics to your friends 
http://www.msn.co.uk/messenger

Re: Traits

["J.Pietschmann" <j3...@yahoo.de>]

Glen Mazza wrote:
> Are we sure it should return 0?  Shouldn't there be a
> difference between "no value" given, and a value of
> "0" given, esp. in cases when you need to calculate
> inheritance?

The spec uses "trait" for a resolved property. There is
no inheritance for traits. I'd guess Keiron choose the
name properly...

J.Pietschmann

RE: Traits

[Victor Mote <vi...@outfitr.com>]

Glen Mazza wrote:

> I think we moved from int-->Integer for properties
> just recently (Victor did, I believe, in prodding from
> Peter Herweg?) because we precisely need NULLs to be
> returned sometime.  (0 won't always be correct.)

That was only in the RTF Renderer -- it didn't affect the FO Tree or Area
Tree at all.

Victor Mote

Re: Traits

[Glen Mazza <gr...@yahoo.com>]

Are we sure it should return 0?  Shouldn't there be a
difference between "no value" given, and a value of
"0" given, esp. in cases when you need to calculate
inheritance? I think so...

I think we moved from int-->Integer for properties
just recently (Victor did, I believe, in prodding from
Peter Herweg?) because we precisely need NULLs to be
returned sometime.  (0 won't always be correct.)

OTOH, if you notice in the Area.RegionViewport class I
recently put some helper classes in such as
getPaddingAndSpacingBefore(), for finding the values
of *specific* properties, where we can make such
"return a 0 if it's NULL"-type determinations.

These helper functions (1) simplify the renderer code
(esp. as the business logic would otherwise be
duplicated in each renderer class), (2) allows code
sharing between the renderers and layout (which also
sometimes needs to calculate these values), and (3)
provides a central point to store property-specific
business logic (e.g., how do we handle a NULL for this
*specific* property system-wide?  Raise exception or a
warning, return 0, return 2 as the default?, etc.,
etc.)  This may be a more accurate route for us--note
for memory concerns, though, I just provided methods
in the RegionViewport to calculate the values, and did
not duplicate the values themselves in RegionViewport.

Glen

--- Chris Bowditch <bo...@hotmail.com> wrote:
> Fop Devs,
> 
> one thing I did notice was a small deficiency in
> Area.getTraitAsInteger(). 
> If the Trait hasnt been set, i.e. the call to
> getTrait returns null, then an 
> exception gets thrown. When Padding is present it is
> perfectly valid as an 
> Integer, so the method should NOT throw an exception
> saying it isnt an 
> integer, when in fact it just isnt present (for that
> block) Instead it 
> should return 0. I have submitted a patch for this.
> 
>
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24705
> 
> Chris
> 
 


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree