Hi FOP'ers

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



Reply via email to