You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@powerup.com.au> on 2003/12/16 17:16:11 UTC
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
gmazza@apache.org wrote:
> gmazza 2003/12/14 17:07:50
>
> Modified: . build.xml
> src/codegen propinc.xsl
> Added: src/codegen constants.xml constants.xsl foelements.xml
> src/java/org/apache/fop/fo Constants.java
> Removed: src/codegen allprops.xml genconst.xsl
> Log:
> 1. Removed the properties.Constants class from automatic generation, and
> added Finn Bock's work on Property and Element Constants (currently unused
> within application.) The CVS version is now the official one. (The
> new constants are not currently being used within the application;
> more work is needed.)
>
> 2. Build.xml has a new helper XSLTtoJAVA task separate from any of the build
> processes to generate the Constants class above (although its output is
> expected to fall behind what will be maintained in the CVS version.)
>
>
> 1.1 xml-fop/src/java/org/apache/fop/fo/Constants.java
>
> Index: Constants.java
> ===================================================================
> /* $Id: Constants.java,v 1.1 2003/12/15 01:07:50 gmazza Exp $
> * ============================================================================
Glen,
Shouldn't this one go into fop/fo/properties?
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
Posted by "Peter B. West" <pb...@powerup.com.au>.
Glen Mazza wrote:
>
> There's about 10-15 differences between Alt-Design and
> HEAD (my unresearched guess), and getting us on to INT
> constants--the no-brainer--removes one of them. Peter
> hopefully will start to see more of the "theory" of
> Alt-Design in HEAD, if not exactly the same
> implementation (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.)
Joshua Bloch, in an interview about the new features in 1.5, refers to
the "Constant Interface" anti-pattern, and briefly discusses why it's
not a good idea. The discussion of Typesafe Enum pattern in association
with the new Typesafe enums in 1.5 may be useful in HEAD. Alt.design
needs ints because I access everything to do with properties through
arrays indexed by the property int constant, but that is probably not an
issue in HEAD.
http://java.sun.com/features/2003/05/bloch_qa.html
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
Posted by Finn Bock <bc...@worldonline.dk>.
>>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.
[Glen Mazza]
> Oh no--I hope you don't mean we have to revert to
> strings for those?
No, not at all. It is just that the element id's for extensions must be
assigned dynamically. Something along the lines of:
in FONode (or anywhere else):
private static int _elementId = Constants.ELEMENT_COUNT;
synchronized public static int makeElementIdentifier() {
return ++_elementId;
}
and in each and every extension subclass of FONode this boilerplate:
private static int elementId = makeElementIdentifier();
public int getElementId() {
return elementId;
}
> Using that logic, property
> constants wouldn't work either, right? (because
> extension elements can have different properties).
At the moment, my performance experiment does not support extension
properties either, but it can be added like this:
- An API that allow the extension to assign values to its property
identifiers dynamically, like elementId above.
- An API that allow the extension to inserts its properties into the
bitset of the parent elements. Otherwise extension property values can
not be inherited from the normal fo: elements. (BTW, this is a good
argument for calculating the full inheritance bitset at runtime).
A change to int elementId's and properties along the lines of my
experiment, would mean a somewhat higher burden on extension writers.
regards,
finn
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
Posted by Glen Mazza <gr...@yahoo.com>.
--- Finn Bock <bc...@worldonline.dk> 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/
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
Posted by Finn Bock <bc...@worldonline.dk>.
[Glen Mazza]
> It's been in that location for at least several
> months--it's just that we never saw it because it was
> autogenerated and never checked into CVS. (As for its
> location--it is used by the FO classes and it also has
> some FO constants and other enumerations in there, so
> it is OK remaining there, I think.)
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;
So you really should move the file from
src/java/org/apache/fop/fo/Constants.java
to
src/java/org/apache/fop/fo/properties/Constants.java
> [...](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.
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
RE: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
Posted by Glen Mazza <gr...@yahoo.com>.
It's been in that location for at least several
months--it's just that we never saw it because it was
autogenerated and never checked into CVS. (As for its
location--it is used by the FO classes and it also has
some FO constants and other enumerations in there, so
it is OK remaining there, I think.)
I pulled that class off its autogenerated pedestal and
checked it into CVS. Also added Finn's properties and
fo constants, or slight variations of them. The
latter are still unused--there's more work needed to
be done to get us on to int constants. I've been
working on it continuously--after work and on
weekends, since about Saturday.
And we may also need to rearrange the property
constants if we're to use Alt-Design's resolution
method, I don't want to gratuitously have Peter's
implementation ruled out just because of the ordering
of some constants. (Now ruling them out if his method
proves sluggish, OTOH, is another matter... ;) But
I'm not there yet.
There's about 10-15 differences between Alt-Design and
HEAD (my unresearched guess), and getting us on to INT
constants--the no-brainer--removes one of them. Peter
hopefully will start to see more of the "theory" of
Alt-Design in HEAD, if not exactly the same
implementation (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.)
Glen
--- "Andreas L. Delmelle" <a_...@pandora.be>
wrote:
> > -----Original Message-----
> > From: Peter B. West [mailto:pbwest@powerup.com.au]
> > >
> > >
> > > 1.1
> xml-fop/src/java/org/apache/fop/fo/Constants.java
> > >
> > > Index: Constants.java
> > >
>
===================================================================
> > > /* $Id: Constants.java,v 1.1 2003/12/15
> 01:07:50 gmazza Exp $
> > > *
> >
>
==================================================================
> > ==========
> >
> > Glen,
> >
> > Shouldn't this one go into fop/fo/properties?
> >
>
> This one puzzles me as well... In the props design
> in head, I found a lot of
> little interfaces declaring static finals with
> values from the
> fop.fo.Constants class.
>
> Anyone?
>
>
> Cheers,
>
> Andreas
>
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
RE: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
> >
> >
> > 1.1 xml-fop/src/java/org/apache/fop/fo/Constants.java
> >
> > Index: Constants.java
> > ===================================================================
> > /* $Id: Constants.java,v 1.1 2003/12/15 01:07:50 gmazza Exp $
> > *
> ==================================================================
> ==========
>
> Glen,
>
> Shouldn't this one go into fop/fo/properties?
>
This one puzzles me as well... In the props design in head, I found a lot of
little interfaces declaring static finals with values from the
fop.fo.Constants class.
Anyone?
Cheers,
Andreas