Finn Bock wrote:

> 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.

It is good to know that there are people doing this.

> 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.

Yes, one of the drawbacks to the Visitor pattern is that its feasibility
depends on a relatively stable data structure.

> 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.

I am assuming from your proposal that you do not wish to directly modify
AddLMVisitor in your custom code, which I understand. If you don't mind,
let's keep your proposal in mind as a last resort, to be used only if we
can't find a better way. The solution that I am leaning toward is to have
you subclass AddLMVisitor instead. If we then give you a set accessor in
LayoutManagerLS to set the subclass, and we use what is stored there, do you
have a place in your code where you can conveniently use that accessor to
set a subclass instead of AddLMVisitor?

Victor Mote

Reply via email to