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

Reply via email to