DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker ------- Additional Comments From [EMAIL PROTECTED] 2004-01-17 01:05 ------- Please give me a couple of days to comment--say 48 hours. My initial thoughts are "I like what I see", esp. since appeared to you appeared to unnest the Property.Maker, which looks good, but I'd like to study the code further. Everything looks good though. [Sorry for the delays this week--I was held up on other things--also was sending some emails to W3C trying to understand which properties can be specified to which FO. See http://lists.w3.org/Archives/Public/xsl- editors/2004JanMar/] One difference we have, I can work on, is that I'm not yet ready to get rid of all those interfaces. The current interface implementation is awful and useless--code-generated, separated into 45 different files, not visible while one is coding, etc., etc. I'd like to have them retained, but put into (1) file, actually, just added to the Constants interface (as inner interfaces), say adding about 600 lines in that interface for them all. (I can modify the XSLT code to accomplish that.) We get rid of those 45 files, and they will be no longer autogenerated with each build (but, as with the current Constants.java, we retain the XSLT to re- generate it when we like.) Reason why? I *think*, over the long-term, it is much more programmer-friendly because many/most developers use IDE's with code-complete. I.E., you type in the property value interface name, hit the ".", and then you automatically see the 5-7 values relevant for that property. This saves the programmer the headache of looking at the spec each time for which prop values you need to code against, or trying to recall from a huge Constants list the actual values you need, and also making sure all the property options have been coded against. I think it will be a nice sanity-saver for coders. If not, we can always excise them later from Constants.java. Thoughts on this? The only other issue right now--not necessarily related to your patch--is that I'd like us, where possible, to start abstracting the propertyList away from the Layout and Renderers, possibly also the Area Tree. (This was an idea originally put forth by Victor a few weeks back, to general agreement on the list.) FObj already has a getProperty() function which just wraps its internal propertyList.getProperty()--and it's already used in a dozen or so places. Instead of layoutManager calling prop = propList.getProperty() left and right, it will be prop = fObj.getProperty(). This will give us some freedom in how we implement properties without needing to make changes to other parts of our code (i.e., we can even get rid of propertyList.) Thanks, Glen