Victor, I find this certainly interesting. IN principle, it would allow client programs, say an editor, to construct its own implementation of the FOTree interface.
Simon On Sat, Sep 03, 2005 at 04:45:33PM -0600, Victor Mote wrote: > FWIW, I completed today the extraction of a set of interfaces for aXSL to > generically describe an FO Tree. The FOray FOTree implements these > interfaces, and the other FOray modules have been changed to use the aXSL > interfaces instead of the FOray FOTree implementation. The only dependency > within FOray on FOray FOTree now is one that handles creating a default > implementation if none is passed to FOraySession. > > For some time now, the FOray FOTree has been available as an independent > module. This new set of interfaces theoretically allow non-FOray FOTree > implementations to be used within FOray. I realize that there is not a great > demand for this ATM. However, there are numerous immediate benefits: > 1. It is now possible to more clearly "show" rather than merely "tell" the > "where" and "when" issues that I described in another thread earlier this > week. > 2. There is something about having to extract an interface that forces one > to address ugly design issues and get them cleaned up. I found and fixed a > few. There are probably still some others that will become apparent in a > closer review of the interfaces. > 3. It opens the door to the possibility of comparing different FO Tree > implementations to each other with other components remaining fixed. I don't > know whether the FOP FO Tree can be adapted to implement this interface or > not, but I suspect that it can. > > For any who are interested, the code can be conveniently viewed here: > http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-fotree/src/java/org/axs > l/fotree/ > > The slightly bad news for Jeremias is that the outer-level FOray API has > changed to accommodate the new FOTreeServer that allows this pluggability. > However, this is easily fixed by passing one more "null" parameter in the > FOraySession constructor. > > The interfaces are not well documented ATM and are no doubt weak in many > other ways as well. A great many of the interfaces are empty markers, > providing type identification only. There may be a better way to handle > this. Or it may turn out that additional methods will need to be added to > them to accommodate more sophisticated needs. > > I hope this is of general interest to this list, and apologize if it is not. > > Victor Mote > -- Simon Pepping home page: http://www.leverkruid.nl
