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.
And it would be a disaster for me if this ability was removed.
I am assuming from your proposal that you do not wish to directly modify
AddLMVisitor in your custom code,
Correct.
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?
I think that would work for me just as well assuming the accessor is somehow available from the Driver instance.
The acceptVisitor method in my TextField extension would then look like this:
public void acceptVisitor(FOTreeVisitor fotv) {
((MyLMVisitor) fotv).serveVisitor(this);
}and I must add a serveVisitor method to MyLMVisitor
public void serveVisitor(TextField node) {
...
}That is quite elegant (except for the cast in acceptVisitor).
I'm not sure how a AddLMVisitor subclass would work if two different extensions are used in the same document, but that is not an issue in my use.
regards, finn
