Glen Mazza wrote: > I'm confused about seeing Bookmarks referenced in > FOTreeControl.java--I thought our pluggable
FOTreeControl is an abstraction of Document, and (by reference) of Driver so that the FO Tree construction process can (eventually) be run by any object that implements that interface. I just added the reference to Bookmarks yesterday. In the old logic the Bookmarks were added to the Area Tree during the FO Tree construction (specifically when the end() method for the Bookmarks element was reached). In the new logic, the end() method stores the Bookmarks object as an instance variable in the FOTreeControl implementation, then the LayoutStrategy implementation performs the same logic that used to be done during end(). Seems to work properly, and untangles another small piece of layout work from the FO Tree construction. > FOTreeControl.java--I thought our pluggable > ElementMappings (including the Bookmark formatting > object) were designed to run with zero internal > hardcoding outside that ElementMapping. I haven't changed anything on ElementMapping at all. The hard-coded logic for dealing with Bookmarks has simply moved to another location. I don't think your statement about hardcoding outside the ElementMapping is *generally* correct. There are some instances (I forget which, but SVG will probably be one at some point in time) where the foreign XML is basically passed through FOP intact to the output, and we want to make that capability generally available with the pluggable ElementMapping. However, there are other extensions, Bookmarks for example, where to be useful, FOP has to do something with them. (BTW, I realized afterward that it would probably have been better to store the Bookmarks object in the Root object instead of the FOTreeControl implementation. Since there is a one-to-one between FOTreeControl and Root, it is no big logical deal, but probably will clean up the FOTreeControl interface to have it in Root instead. I'll ponder that as I move along). > This is bringing up an earlier issue--we currently > allow runtime loading of user-defined and -invented > ElementMappings, that supposedly can be processed by > FOP, with zero hardcoding outside of that > ElementMapping. For example, a user invents his own > ElementMapping, places it in a certain directory, runs > FOP, and FOP will instantly absorb and use the new > ElementMapping--no hardcoding for it required in Area > Tree, Layout, Renderers, etc. > > I argued for removing that runtime loading capability > a few months back (when I moved this functionality > from Driver to FOTreeBuilder) because it just doesn't > work by itself, i.e., just adding a ElementMapping > won't work, you still need to hardcode all over the > application to accomodate the new formatting object. > (Just like you're doing for Bookmarks, for example.) > But I wasn't sure on that point, and the team > disagreed with me here--saying that no such internal > coding would be needed. If all cases were like Bookmarks, you would be correct I think. However, the major premise fails. You'll have to look at the previous thread for the examples that pass through FOP. (Sorry, I don't use any of them) > So, are we back to square one with the pluggable > ElementMappers idea? Should we rip out that > functionality from FOTreeBuilder that allows FOP to > dynamically load brand-new ElementMappings? I still > don't see its utility. IMO, no, and especially not as a result of this refactoring, which really hasn't changed anything. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
