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

Reply via email to