--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > 1.) For the new PropertyList constructor (in the
> patch), you appear to be 
> > duplicating the element ID argument, once as "el",
> the other time 
> > as "elementId"--just to confirm, they are
> referring to the same thing (and 
> > hence one of them can be removed)?
> 
> Yes, it is a silly leftover from my own conversion
> process.
> 

OK--BTW, what's your opinion on switching to FO
Constants at this time?  They probably will not give
us the rate of return that property constants have;
but there may be future indexing or processing
advantages with them.  I'm not strong one way or the
other on them.

One issue your brought up in the email below, was that
of extension elements needing their own ID's
dynamically:  

http://marc.theaimsgroup.com/?l=fop-dev&m=107182754300725&w=2

Your solution in your email does not look difficult to
implement, but as a simplification, how about just
implementing getElementId() within FONode to query an
new ID if its value is unintialized, say, -1, and to
store that value with the FONode, *instead of* having
each Extension FO's implement that query & store
function themselves?  

> > ----------------
> 
> No, the + 1 is a deliberate trick to handle unknown
> properties which
> should return a null value during lookup().

<snip/>

Excellent--thanks for your full explanation--I
understand it now, and have added comments to
PropertySets.java to make it clearer for others who
may also have questions.


> > ------------------
> > 
> And it includes the properties that are valid for
> all the children element of
> each FO. That is what the large while loop does when
> it calls mergeContent.

OK--but to satisfy the spec, we probably need to add a
static boolean array for the properties, defining
true/false of whether each property is "inheritable". 


Because one can attach an inheritable property to any
FO, regardless of whether or not it is relevant for it
or its children, we don't want to report an error if
the user chooses to do so--we can query this static
array to determine that we should just ignore the
property instead.  I can probably help out with
this--but I'll wait until later when 25873 is
settled--we may end up having this information created
anyway by then.

> , I've concluded that it would also be good design
> decision and I plan
> on updating patch 25873 to show that the
> Property.Maker can become
> simpler and easier to understand as well as faster.
> 

Looking forward to seeing it--I haven't had much time
to look at 25873 yet.  One possible way I see of 
simplifying the makers would be for them to no longer
be a nested inner class of Property, but either part
of the Property class itself or part of its own class.


BTW, when you have write access available, let me know
when you'd like me to step back, I'll happily retreat
back to the renderers and let you take over the
properties at your much faster rate of speed.

Thanks,
Glen


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Reply via email to