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