After the recent refactoring of addLayoutManager into the AddLMVisitor class, I can't quite see how an 3rd part extensions can control how its LM and the area tree nodes is created.
I'm sure there are good reasons for the fo-tree separation and for using a Visitor pattern but it does make adding new FObj sub-classes a bit more difficult, IMHO.
I could continue to handle the creation of LM's in my extension if there was a way to add a LM directly to the AddLMVisitor. So I suggest that AddLMVisitor grows a new method:
public void addLayoutManager(LayoutManager lm) {
currentLMList.add(lm);
}Then the acceptVisitor method in my extension could be something along the lines of:
public void acceptVisitor(FOTreeVisitor fotv) {
if (fotv instanceof AddLMVisitor) {
InlineArea area = getInlineArea();
LeafNodeLayoutManager lm = new LeafNodeLayoutManager();
lm.setFObj(this);
lm.setCurrentArea(area);
((AddLMVisitor) fotv).addLayoutManager(lm);
} else {
fotv.serveVisitor(this);
}
}I'm checking for an AddLMVisitor instance to verify that this fo-tree walk is about adding LM's.
I doubt if this fits with the overall FOP design, but unless I have overlooked an obvious way of controlling LM creation, then something has to be added.
regards, finn
