Hi 

thanks for the quick response from everyone.

> Sounds reasonable to me--I think I should have done the validation
> that way to begin with (IIRC =='s are Not Good with Strings anyway

yes, I think so as well. Since String.equals() does the == check
first anyways there shouldn't be a performance impact. Using
intern() by FO internally might or might not be beneficial
as mentioned. Upfront cost vs. saving memory and comparison effort.

> I am personally pleased that FOP 1.0 is now activatible by directly 
> instantiating FOTreeBuilder, i.e. one can avoid the apps package 
> completely.  This is because FOTreeBuilder now has all its needed 
> business logic within it.  

That was exactly my thinking - I'm planning to embed FOP as well
as xsl-docbook. Going through apps.FOP forces me to package
stuff that I don't really need since it seems to be designed
around running it from the command-line (forcing dependencies
to CommandLineOptions and the avalon stuff).

So embedding something like the FOTreeBuilder that operates
on the xsl level is more intuitive.

> but FOTreeBuilder is within FOP's
> "black box" and may not be available/could be renamed

agreed but for an embedded solution that's a risk I'm 
willing to take :) It would be nice if the layer below
apps.Fop was a public supported API actually.

Thanks for considering that change
Regards
Nils

Reply via email to