>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker
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.
The patch does not unnest the Property.Maker class. It doesn't matter all that much to me, but if it is considered a good idea it is easy to do.
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.)
Should the values of the constants still be globally unique, or just unique within each inner-interface? I would say globally unique since it would be easier to add a int->string method somewhere for debugging.
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?
+1
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.
I think you have mentioned this a couple of times before, but I didn't understand it back then either. Perhaps I just doesn't understand what part of our code you consider Renderer and Area Tree. Because I can't find any references to properties or propertyList in the area package or in the pdf and ps renderer.
(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.)
regards, finn
