RE: (Victor et al) Re: Performance improvements.
Peter B. West wrote: Victor Mote wrote: Yes, yes, yes. Since we are trying to eliminate the need for unnecessary object creation, why create a MinOptMax object? Why not just return the three resolved values in separate methods. Anything that uses the information will have to separately address the 3 pieces of data anyway, so I don't see any advantage to packaging them in an object. In fact, in alt.design, getPropertyValue(PropNames.LEADER_LENGTH_MINIMUM) etc. Speaking of the minimal API, why not PropertyValue getPropertyValue(int propertyIndex)? This is presumably defined on FONode or some such, and FONode also presumably knows how to navigate the FO tree and related Area tree in order to resolve percentages and the like. That may be OK for the internal-to-FO-Tree logic, but I don't think is suitable for the API, primarily because you are locked into one signature for all properties. 1) There may be some properties for which we want to return a non-integer value (Font object, for example). 2) There may be some properties for which we wish to pass more information. 3) You are going to have some ugly case or switch logic that has to determine which property is being dealt with. My opinion is that this is not a sound approach. Victor Mote
RE: (Victor et al) Re: Performance improvements.
Peter B. West wrote: Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: See above. In alt.design, all compounds are shorthands, and all shorthands are presumed to have been resolved into their components during FO Tree building. BTW, does Alt-Design already resolve the cases where *both* a shorthand and one of its included components are specified? I.e., (usually, I believe), disregard the shorthand value for that component and use its explicitly given value instead? It's in the ordering of the properties. There is a simply for loop to process properties (attributes, in fact) defined on an FO. The order of definition ensures the correct order of evaluation - shorthand first, then any individual properties. The same goes for corresponding properties, when I get around to doing them. Check the order of properties in PropNames.java. I don't know how to reconcile this with your previous posting: See above. In alt.design, all compounds are shorthands, and all shorthands are presumed to have been resolved into their components during FO Tree building. The previous posting seems to indicate that the properties have been decomposed, the chronologically latter posting seems to indicate that the shorthand retains its shorthand character. The critical thing here is that the API not even allow anybody to ask about shorthand or compound properties. The API should allow requests only for the decomposed properties, and the FO Tree should resolve all of this before passing a value back. Victor Mote
RE: (Victor et al) Re: Performance improvements.
Peter B. West wrote: If we go towards integer representation, properties in the API will always be represented by integers. By looking at this particular signature, we are not locking ourselves in. We can add other signatures if the need arises, but they can be extensions of the basic call. The above call does not return an int or an Integer, but a PropertyValue. public PropertyValue getPropertyValue(int property) is, in fact, the signature from FONode.java in alt.design. OK. I'll interpret this as a firm -1 on my API proposal, which is sufficient to deep-six it. I think it will be a net benefit for the project for me to withdraw from the remainder of the Properties discussion. Victor Mote
Re: (Victor et al) Re: Performance improvements.
Victor Mote wrote: Peter B. West wrote: Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: See above. In alt.design, all compounds are shorthands, and all shorthands are presumed to have been resolved into their components during FO Tree building. BTW, does Alt-Design already resolve the cases where *both* a shorthand and one of its included components are specified? I.e., (usually, I believe), disregard the shorthand value for that component and use its explicitly given value instead? It's in the ordering of the properties. There is a simply for loop to process properties (attributes, in fact) defined on an FO. The order of definition ensures the correct order of evaluation - shorthand first, then any individual properties. The same goes for corresponding properties, when I get around to doing them. Check the order of properties in PropNames.java. I don't know how to reconcile this with your previous posting: See above. In alt.design, all compounds are shorthands, and all shorthands are presumed to have been resolved into their components during FO Tree building. The previous posting seems to indicate that the properties have been decomposed, the chronologically latter posting seems to indicate that the shorthand retains its shorthand character. The critical thing here is that the API not even allow anybody to ask about shorthand or compound properties. The API should allow requests only for the decomposed properties, and the FO Tree should resolve all of this before passing a value back. The ordering is necessary to ensure that the FO attributes are processed in the correct sequence. When the properties on a particular node and its subtree are fully parsed, the shorthands and compounds will have been expanded, and the minimal property set for the stable FO tree is constructed. See makeSparsePropsSet() in FONode.java at http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/fo/FONode.java?content-type=text%2Fplainrev=1.2.2.1 Within getPropertyValue() these situations are discriminated, according to the comments on private PropertyValue[] propertySet; When the properties for this value are still being resolved, getPropertyValue() will resolve inheritance and initial values. During this process, shorthands and compounds will be resolved. At the time the subtree of the FONode has been constructed, the property set of the node will be reduced (by makeSparsePropsSet()), and the shorthands and compounds will be eliminated. A call to getPropertyValue() specifying such a property will presently, IIRC, throw an exception. If necessary, that can be adjusted to return a NoType PropertyValue, but the assumption is that by this stage, anything calling for a resolved property will be aware of which properties are valid on the node. In either case, any other method which requests such a value is going to get short shrift. I think that covers the last couple of sentences in your comment above. Basically, shorthands, etc, get resolved and eliminated from the valid property set. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
Victor Mote wrote: Peter B. West wrote: If we go towards integer representation, properties in the API will always be represented by integers. By looking at this particular signature, we are not locking ourselves in. We can add other signatures if the need arises, but they can be extensions of the basic call. The above call does not return an int or an Integer, but a PropertyValue. public PropertyValue getPropertyValue(int property) is, in fact, the signature from FONode.java in alt.design. OK. I'll interpret this as a firm -1 on my API proposal, which is sufficient to deep-six it. I think it will be a net benefit for the project for me to withdraw from the remainder of the Properties discussion. Victor, I thought that my input on this question was primarily informational. If I wanted to vote -1 on your proposal, I would. I did not, and still do not, intend to vote on that proposal, because 1) my primary involvement is with alt.design, and 2) I don't understand it. (I will post again shortly on the slowness of my understanding in general.) If your proposal is deep sixed, it will be by those who are more intimately involved in HEAD, and who fully understand what you are trying to achieve. My comments about the use of integers are based entirely on my experience with alt.design, which I thought might be helpful in coming up with a modified properties handler in HEAD. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
Victor Mote wrote: Peter B. West wrote: It would be really nice to have a getLeaderLength() which returns a MinOptMax. this means the getLeaderLength() has: - resolve percentages and functions - deal with the leader-length shorthand setting before this - deal with inheritance (n/a here, fortunately) Or getLeaderLengthMin(), getLeaderLengthOpt(), getLeaderLengthMax(), with all values resolved. Yes, yes, yes. Since we are trying to eliminate the need for unnecessary object creation, why create a MinOptMax object? Why not just return the three resolved values in separate methods. Anything that uses the information will have to separately address the 3 pieces of data anyway, so I don't see any advantage to packaging them in an object. In fact, in alt.design, getPropertyValue(PropNames.LEADER_LENGTH_MINIMUM) etc. Speaking of the minimal API, why not PropertyValue getPropertyValue(int propertyIndex)? This is presumably defined on FONode or some such, and FONode also presumably knows how to navigate the FO tree and related Area tree in order to resolve percentages and the like. Joerg speaking here/ One of the complications in the maintenance code is that the code in the FO layout routines had to deal with resolving percentages. OTOH, the generator is mainly so ugly because Keiron et al. tried hard to press the shorthand handling into a common scheme. There should be better solutions for either problem. Nobody but the FO Tree should ever have to think about compound or shorthand properties. AFAICT, all examples of these can be decomposed into their components. The FO Tree's API should deliver only the decomposed (i.e. lowest-common-denominator or LCD) values. And yes, definitely, percentages should be handled on the FO Tree side. Make FO Tree do all of that work. See above. In alt.design, all compounds are shorthands, and all shorthands are presumed to have been resolved into their components during FO Tree building. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
--- Peter B. West [EMAIL PROTECTED] wrote: See above. In alt.design, all compounds are shorthands, and all shorthands are presumed to have been resolved into their components during FO Tree building. BTW, does Alt-Design already resolve the cases where *both* a shorthand and one of its included components are specified? I.e., (usually, I believe), disregard the shorthand value for that component and use its explicitly given value instead? Thanks, Glen __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Re: (Victor et al) Re: Performance improvements.
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: See above. In alt.design, all compounds are shorthands, and all shorthands are presumed to have been resolved into their components during FO Tree building. BTW, does Alt-Design already resolve the cases where *both* a shorthand and one of its included components are specified? I.e., (usually, I believe), disregard the shorthand value for that component and use its explicitly given value instead? It's in the ordering of the properties. There is a simply for loop to process properties (attributes, in fact) defined on an FO. The order of definition ensures the correct order of evaluation - shorthand first, then any individual properties. The same goes for corresponding properties, when I get around to doing them. Check the order of properties in PropNames.java. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
Good thing I asked--I may need to do that with the Constants interface, where the ordering is currently alphabetical. Glen --- Peter B. West [EMAIL PROTECTED] wrote: It's in the ordering of the properties. There is a simply for loop to process properties (attributes, in fact) defined on an FO. The order of definition ensures the correct order of evaluation - shorthand first, then any individual properties. The same goes for corresponding properties, when I get around to doing them. Check the order of properties in PropNames.java. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Re: (Victor et al) Re: Performance improvements.
[Glen Mazza]
Thanks, Finn and John Austin, for your efforts here.
It's a pleasure.
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and liked what I saw. It doesn't necessarily have to
be that particular design, just the idea of integer
constants in general.
For inspiration you can also take a look at some of the same files that
I made:
http://bckfnn-modules.sf.net/Constants.java
http://bckfnn-modules.sf.net/FOPropertyMapping.java
http://bckfnn-modules.sf.net/PropSets.java
The PropSets.java file is created from a new .xml file that specifies
the element and property structure.
http://bckfnn-modules.sf.net/foelements.xml
Perhaps the information in PropSets.java could also be created from a
xsl-fo DTD.
In addition to the performance improvements,
I suggested before we could have some form of
// very rough pseudocode
checkPropertySupported (int property) {
return isSupported[property];
}
That would be written like this:
boolean checkPropertySupported (int property) {
return indices[i] != 0;
}
It appears that using int constants gives us more ways
to efficiently work with the data.
I agree.
regards,
finn
Re: (Victor et al) Re: Performance improvements.
[J.Pietschmann] [snip] If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. I like the generation process as it allowed me to try out and experiment with different optimizations. I don't think that I realisticly could have added caching of compound properties or changed the abs2rel/rel2abs code if I had to change the Maker classes manually. regards, finn
Re: (Victor et al) Re: Performance improvements.
+1 to that, but please don't dump the original XML files (foproperties.xml etc.) because they could come handy later. Besides that, I can't contribute much to this discussion, but I am confident that you guys find a good solution. The integer idea sounds reasonable to me and I'm particularly glad that a few new smart heads start to get active on HEAD. Thank you for your efforts! On 13.12.2003 01:34:02 J.Pietschmann wrote: If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. Jeremias Maerki (who's still looking for a way out of his current Delphi swamp)
Re: (Victor et al) Re: Performance improvements.
Finn Bock wrote: I like the generation process as it allowed me to try out and experiment with different optimizations. I don't think that I realisticly could have added caching of compound properties or changed the abs2rel/rel2abs code if I had to change the Maker classes manually. If its common code, that's what class hierarchies and inheritance are made for. J.Pietschmann
Re: (Victor et al) Re: Performance improvements.
-1. I'd like to hold off on this, at least until I can gain a better understanding of the autogenerated code. I may still to the same conclusion as the other committers, but Finn's endorsement of the XSLT--as well as the long work of those like Keiron who have worked with the XSLT files--suggests that there are significant time benefits to using them. (At work, I use SQL to write SQL all the time, and love the time efficiencies that result.) If we check in the Java code, then changes may end up being made to those files directly, which will result in the XSLT files becoming unregeneratable. Or, every run of the XSLT will require re-modification of the changes made manually to all the Java files--potentially dozens--100's of files. So I'm kind of leery about doing this at the moment. [Actually, I'm looking forward to studying the XSLT that generates these files--as I mentioned to Clay that CVS and Ant were two of the initial benefits you get by working on FOP, apparently being about to write Java code using XSLT is a third one...i.e., Yeehaw!, as I believe he had put it... ;)] Glen --- J.Pietschmann [EMAIL PROTECTED] wrote: Finn Bock wrote: I like the generation process as it allowed me to try out and experiment with different optimizations. I don't think that I realisticly could have added caching of compound properties or changed the abs2rel/rel2abs code if I had to change the Maker classes manually. If its common code, that's what class hierarchies and inheritance are made for. J.Pietschmann __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Re: (Victor et al) Re: Performance improvements.
I haven't looked at the XSLT code but I have a question in my mind that I need to answer about it. I wonder what it is that is being generated and what were the design alternatives to the codegen implementation. One question that popped in to my head was: Is there 'missing polymorphism' here ? As I said, I only have the question at this time. On Sat, 2003-12-13 at 12:12, Glen Mazza wrote: -1. I'd like to hold off on this, at least until I can gain a better understanding of the autogenerated code. I may still to the same conclusion as the other committers, but Finn's endorsement of the XSLT--as well as the long work of those like Keiron who have worked with the XSLT files--suggests that there are significant time benefits to using them. (At work, I use SQL to write SQL all the time, and love the time efficiencies that result.) If we check in the Java code, then changes may end up being made to those files directly, which will result in the XSLT files becoming unregeneratable. Or, every run of the XSLT will require re-modification of the changes made manually to all the Java files--potentially dozens--100's of files. So I'm kind of leery about doing this at the moment. [Actually, I'm looking forward to studying the XSLT that generates these files--as I mentioned to Clay that CVS and Ant were two of the initial benefits you get by working on FOP, apparently being about to write Java code using XSLT is a third one...i.e., Yeehaw!, as I believe he had put it... ;)] Glen --- J.Pietschmann [EMAIL PROTECTED] wrote: Finn Bock wrote: I like the generation process as it allowed me to try out and experiment with different optimizations. I don't think that I realisticly could have added caching of compound properties or changed the abs2rel/rel2abs code if I had to change the Maker classes manually. If its common code, that's what class hierarchies and inheritance are made for. J.Pietschmann __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- John Austin [EMAIL PROTECTED]
Re: (Victor et al) Re: Performance improvements.
Glen Mazza wrote: -1. I'd like to hold off on this, at least until I can gain a better understanding of the autogenerated code. I may still to the same conclusion as the other committers, but Finn's endorsement of the XSLT--as well as the long work of those like Keiron who have worked with the XSLT files--suggests that there are significant time benefits to using them. (At work, I use SQL to write SQL all the time, and love the time efficiencies that result.) Well, the XSLT generation of the Java classes was good for bootstrap, because the properties were gained from the XML source of the spec. The FO java classes were bootstrapped this way too. This came handy while the spec was in flux and properties and elements were added and changed. Remember, FOP tracked the spec from the early development, and some bugs like the white-space-collapse peciliarities are leftovers from this phase. Unfortunately, meanwhile generating has become more of a burden, because if you look at in in detail, there are very, very few properties which are handled identically. Catering for the fine differences has led to many ugly hooks in the presumably generic code (have a look at GenericShorthandParser, which isn't generic enough to parse font shorthand properties). [Actually, I'm looking forward to studying the XSLT that generates these files--as I mentioned to Clay that CVS and Ant were two of the initial benefits you get by working on FOP, apparently being about to write Java code using XSLT is a third one...i.e., Yeehaw!, as I believe he had put it... ;)] Well, I fell for the trap too...I'm all in for code generators, and I regularly use some and write some for myself. However, code generation has to have benefits, and if I have to provide 183 choose cases for individual code for (a fixed number of) 185 items, there is no longer any reasonable benefit. A class hierarchy, and some proper abstractions should be enough to avoid code duplication. If I had time I'd even rewrite the propery code nearly from scratch, because - provide a proper property expression tree - deal with shorthands and font family selections in a less convoluted way - perhaps use a grammar driven parser for property expressions The intermingling of (improper) tokenizing, top-down parsing and error handling for property expressions as well as the improper reuse of tokenizing for shorthand parsing (despite it being a completely different grammar) was always enough to drive my blood pressure through the roof. J.Pietschmann
Re: (Victor et al) Re: Performance improvements.
I like the generation process as it allowed me to try out and
experiment with different optimizations. I don't think that I
realisticly could have added caching of compound properties or changed
the abs2rel/rel2abs code if I had to change the Maker classes manually.
[J.Pietschmann]
If its common code, that's what class hierarchies and
inheritance are made for.
Indeed, but then I think you are talking about a cleaner rewritten
property handling class hierarchies, right?
But in what we have generated now, the similarities isn't handled by
inheritance. So there is a certain amount of repeated-but-not-equal code
in the Maker classes.
For instance, the 22 makers with isCorrespondingForced() methods,
generates this kind of code in HEAD:
public boolean isCorrespondingForced(PropertyList propertyList) {
FObj parentFO = propertyList.getParentFObj();
StringBuffer sbExpr=new StringBuffer();
sbExpr.setLength(0);
sbExpr.append(margin-);
sbExpr.append(propertyList.wmRelToAbs(PropertyList.START));
if (propertyList.getExplicit(sbExpr.toString()) != null)
return true;
return false;
}
and my optimized code looks like this:
public boolean isCorrespondingForced(PropertyList propertyList) {
FObj parentFO = propertyList.getParentFObj();
if (propertyList.getExplicit(propertyList.wmMap(
Constants.P_MARGIN_LEFT,
Constants.P_MARGIN_RIGHT,
Constants.P_MARGIN_TOP)) != null)
return true;
return false;
}
Another optimization that I would like to try out, involves creating a
copy of the PropertyList.findProperty() method in the Maker classes,
but one that doesn't call isCorrespondingForced() if the maker knows
that it always return false and doesn't call getExplicit if there isn't
any shorthands defined. Such an experiment is downright impossible if
the Maker isn't generated.
regards,
finn
RE: (Victor et al) Re: Performance improvements.
Glen Mazza wrote: Thanks, Finn and John Austin, for your efforts here. Yes, and Peter, too. Victor, not to rush you, but how agreeable are you in general on switching to integer enumerations for FOP properties? (Given Alt-Design, Peter obviously approves.) I checked Alt-Design's PropNames.java[1] and liked what I saw. It doesn't necessarily have to be that particular design, just the idea of integer constants in general. That is fine. I hope nothing I have said would be interpreted to the contrary, and I can't imagine why you might think that this proposition rushes me (were you waiting on me for something?). I have the least knowledge of or interest in the performance side. Having said that, I *very* much want us to implement a lowest-common-denominator, it-will-never-matter-what-the-guts-look-like API for the FO Tree to deliver the property values. That is totally independent of the way properties are stored and computed. Victor Mote
RE: (Victor et al) Re: Performance improvements.
Peter B. West wrote: It would be really nice to have a getLeaderLength() which returns a MinOptMax. this means the getLeaderLength() has: - resolve percentages and functions - deal with the leader-length shorthand setting before this - deal with inheritance (n/a here, fortunately) Or getLeaderLengthMin(), getLeaderLengthOpt(), getLeaderLengthMax(), with all values resolved. Yes, yes, yes. Since we are trying to eliminate the need for unnecessary object creation, why create a MinOptMax object? Why not just return the three resolved values in separate methods. Anything that uses the information will have to separately address the 3 pieces of data anyway, so I don't see any advantage to packaging them in an object. Joerg speaking here/ One of the complications in the maintenance code is that the code in the FO layout routines had to deal with resolving percentages. OTOH, the generator is mainly so ugly because Keiron et al. tried hard to press the shorthand handling into a common scheme. There should be better solutions for either problem. Nobody but the FO Tree should ever have to think about compound or shorthand properties. AFAICT, all examples of these can be decomposed into their components. The FO Tree's API should deliver only the decomposed (i.e. lowest-common-denominator or LCD) values. And yes, definitely, percentages should be handled on the FO Tree side. Make FO Tree do all of that work. Victor Mote
RE: (Victor et al) Re: Performance improvements.
J.Pietschmann wrote: If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. +1. I have noted Finn's and Glen's subsequent objections, and Joerg's subsequent comments. I agree that the general need for that level of flexibility has passed, and that these things *should* be rewritten in a more OO way. I may be wrong, but I think most of these classes will disappear after this stuff is properly rationalized. The vast majority of the values can be reduced to primitive data types that can be stored directly in FO Object instances. I think one other advantage of the generated code was that it was easier to deal with whether a property was supported or not. However, support for properties now needs to be handled by the LayoutStrategy implementations. IOW, as far as FO Tree is concerned, it handles all objects and properties, and should remain agnostic about how that information may or may not be used. Victor Mote
Re: (Victor et al) Re: Performance improvements.
Glen Mazza wrote: Victor, not to rush you, but how agreeable are you in general on switching to integer enumerations for FOP properties? (Given Alt-Design, Peter obviously approves.) I checked Alt-Design's PropNames.java[1] and liked what I saw. It doesn't necessarily have to be that particular design, just the idea of integer constants in general. There are some ugly considerations. I think at the FO level properties should be prepared into redy-to-use bundles. At some point something has to deal with the oddities called compound properties. It would be really nice to have a getLeaderLength() which returns a MinOptMax. this means the getLeaderLength() has: - resolve percentages and functions - deal with the leader-length shorthand setting before this - deal with inheritance (n/a here, fortunately) One of the complications in the maintenance code is that the code in the FO layout routines had to deal with resolving percentages. OTOH, the generator is mainly so ugly because Keiron et al. tried hard to press the shorthand handling into a common scheme. There should be better solutions for either problem. If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. J.Pietschmann
Re: (Victor et al) Re: Performance improvements.
J.Pietschmann wrote: Glen Mazza wrote: Victor, not to rush you, but how agreeable are you in general on switching to integer enumerations for FOP properties? (Given Alt-Design, Peter obviously approves.) I checked Alt-Design's PropNames.java[1] and liked what I saw. It doesn't necessarily have to be that particular design, just the idea of integer constants in general. There are some ugly considerations. I think at the FO level properties should be prepared into redy-to-use bundles. At some point something has to deal with the oddities called compound properties. They're shorthands, with some slightly different inheritance characteristics. I think Arved may have come to the same conclusion. It would be really nice to have a getLeaderLength() which returns a MinOptMax. this means the getLeaderLength() has: - resolve percentages and functions - deal with the leader-length shorthand setting before this - deal with inheritance (n/a here, fortunately) Or getLeaderLengthMin(), getLeaderLengthOpt(), getLeaderLengthMax(), with all values resolved. One of the complications in the maintenance code is that the code in the FO layout routines had to deal with resolving percentages. OTOH, the generator is mainly so ugly because Keiron et al. tried hard to press the shorthand handling into a common scheme. There should be better solutions for either problem. While I haven't done the corresponding properties for alt.design yet, shorthand and compound properties are handled, if not prettily, at least coherently. Percentages will. I think, be resolved by tightly integrating the processing of FO nodes and areas within PageSequence, so that these values are resolved as early as possible. For example, the relevant reference-area will be made available from the area construction logic to the FO tree builder for resolution of the properties at the time of parsing. In most cases, the area will be dimensioned at this time, but where not, the linkage between FO node and area will be established. If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. +1 Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
