--- Finn Bock <[EMAIL PROTECTED]> wrote: > I think Peter was refering to the fact that you > placed the file in the > src/java/org/apache/fop/fo/ > directory, but it used to be in the > org.apache.fop.fo.properties. > package. Indeed, the package statement in the > Constants still reads > package org.apache.fop.fo.properties; >
Yes, I foolishly realized later that's what Peter meant (I'm surprised it compiled w/o error though--that was my confusion, since there was no error I assumed he was commenting on my choice of location for the package.) > > > [...](e.g., like Finn, I have a slight > > preference for a constants > > interface--Constants.java--that classes can > implement, > > rather than a constants class--PropNames.java.) > > Right, but methods that can map constants->string > and string->constants > is still needed and must be placed in a class > somewhere. I happened to > put the methods in the FOPropertyMapping class. > I'll look at that--I'm currently trying to move the constants over right now. > > Also, while I used fo:element constants in my > experiment, it is clear to > me that such an approach does not work well for > extension elements. > > regards, > finn > Oh no--I hope you don't mean we have to revert to strings for those? Using that logic, property constants wouldn't work either, right? (because extension elements can have different properties). At worst, I hope we can use overloaded functions (constants in some cases, strings in others.) Thanks, Glen __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/