Victor Mote wrote:
> Finn Bock wrote:
> > 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 would like to get rid of the cast as well, as my goal is to maintain the
> FOTree as an independent module (especially that it doesn't need any
> information about layout). Assuming that "this" is a (direct or indirect)
> subclass of FONode, I think the cast should be unnecessary, but
> I'll test it
> on this end to make sure first.
>
> After looking at the code for a bit, I need to stop and tie some of the
> pieces of the LM Tree together a bit better. Right now I am creating an
> AddLMVisitor for each iterator, which is not what I want. It will
> take me a
> while to get that pushed up to LayoutManagerLS and to tie the LM Tree to
> that. I'll post back after I get it done, hopefully before the weekend is
> out.
Finn:
OK. I just committed a set of changes that should get you going. You will
need to create an instance of your subclass, then use the
LayoutManagerLS.setAddLMVisitor method to tell FOP to use that. Also I added
some accessor methods in AddLMVisitor that will give your subclass access to
the list objects that are there, as you will probably need them.
I tested it on my side by commenting out the method for "Block" in
AddLMVisitor, and creating a subclass that had only "Block" in it. I watched
it go through the debugger as expected & the output seemed fine. (That was
without any casting -- unless I am missing something, you should be able to
eliminate the cast in your code as well, and I recommend that you do so, as
the build process may eventually compile the FO Tree code in isolation from
the layoutmgr classes).
Let me know if you see any problems.
Victor Mote
