Chris Bowditch wrote: > I hope you dont me asking, but I am curious about the work you are doing. > Why did you name this object Visitor? What does it mean in terms > of a Layout > Manager? Please understand I'm not trying to critise, I'm just trying to > understand.
It is a good question, and I don't mind at all. A week ago, I would have asked the same question. I actually started to code this another way, and got to thinking "I wonder if this problem fits one of the Gang of Four Design Patterns?" The situation is that we have an FO Tree which is essentially a long chain of subclasses, sub-subclasses, etc. of FONode. A bunch of those classes have addLayoutManager methods. I wanted to factor all of the addLayoutManager code out of the FOTree, but the problem is how to do and still maintain the polymorphic character of the overridden methods down the chain. I knew I didn't want to use (instanceof) operators and long *if* chains if I could help it. The Visitor design pattern gives what seems to be a nice way to handle this. You essentially place hooks in the tree at each node so that the inheritance and polymorphism survive. Then the Visitor sets any state information, and passes *itself* (this was the key insight for me) to the hook, which then turns around and passes itself (i.e. the node in the tree) back to the Visitor, which now knows exactly what subclass in the tree hierarchy it is working with. The real beauty of it is that you can use the same hooks any number of times for any number of Visitors. So anybody that now wants to traverse the FO Tree and do something that depends on what type of node it is working with, without going to the trouble of finding out what type of node that is, can do so by subclassing FOTreeVisitor. I think this will be useful for anyone trying to implement a LayoutStrategy. So the answer to your second question is that the Visitor doesn't have anything to do with the layout managers, except as a means to an end. The only downside that I can see is that the abstract FOTreeVisitor needs to be updated if the super/sub class relationships within the FOTree change. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
