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