--- "Peter B. West" <[EMAIL PROTECTED]> wrote: > > I thought it was generally > agreed some time ago > that my work on properties should be integrated, for > the simple reason > that it is smaller and faster.
Exactly! Now you're talking my language--"smaller and faster"--i.e., something that will generate more same-size reports than trunk will. I want it so that when we get performance complaints such as Brian Minchau/Xalan recently did (http://marc.theaimsgroup.com/?l=xalan-dev&m=105552092525811&w=2) we can confidently state that FOP has the best design possible. However, per the centripetal/centrifugal discussion of Victor (*very* interesting, BTW), we need to see *proof* that it is faster, and to help do that, we should make the code more modular. <repeated boring discussion on the benefits of encapsulated code> That's why I want ElementMappings out of apps package and back into the FOTreeBuilder class. This way, when someone like you has a competing design--no more ElementMappings, use push/pull parsers, widgets, abacuses, chickens, whatever--you only have to change FOTreeBuilder, and not simultaneously 57 places throughout the code. It makes it easier to test/compare different implementations, and less mortifying for such changes to be made because fewer classes need updating. </repeated boring discussion on the benefits of encapsulated code> Secondly, as I mentioned earlier about applying your findings, you've already confirmed for me my suspicions that user-defined ElementMappings won't work because the semantics of those mappings would not be understood by the rest of the code anyway (please contradict me here if I'm wrong)--Great, for 1.0, in addition to moving the DefaultMappings to FOTreeBuilder, we can dispense with the code that allows for users to add on their own mappings. Me applying your findings now--even if in a different implementation--saves you the "Hey, we can't go to push/pull parsers because we'll lose user-defined ElementMappings!!!" argument later. (You'll still have to win the faster argument though... ;) > I repeat that hacking on the code is easier and more > immediately > rewarding than thinking through the design. The > approaches are not > mutually exclusive, and must be mixed, I think. I agree that "hacking" the code would be useless for you, because you understand it--but I need to work on the code/refactor it/keep it clean (I have fun with a local version of FOP) just to understand how FOP works. I have apps mostly understood and am now looking at the layout package. This helps me hold more better conversations with the team. > But, here has been too > much of the former and too little of the latter, > IMO. Agreed. I'm happily looking forward to the day when I can debate you on all implementation issues--even trip you up every now and then--until then, I need to keep working on the code to understand it more, and yes, reading your writings more. Glen __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
