Glen Mazza wrote: > While I'm implementing the validateChildNode() methods, I > would also like to work on removing the AddLMVisitor visitor > pattern[1], and revert to our previous method of having the > FO's themselves setup the LayoutManagers via > addLayoutManager(). (See here [2][3][4] for examples of the > previous way of a year > ago.) > > I believe this change will help make the fundamental > relations between the AreaTreeHandler, the formatting > objects, and the layout managers a bit easier to see, and > will hopefully lead to making layout less complex. > (Architecturally, I'm also not too pleased with the large > amount of FO- and LM-specific business logic that > AddLMVisitor ends up needing to retain.) > > We haven't had any demand yet for the visitor pattern, and we > can always place it in later if needed after the FO/Layout > business logic has been better determined. Any objections?
-0. I'm sorry you asked (again), but since you did, of course I object. The "0" is because I am not a FOP stakeholder, but the "-" is because I am a Friend of FOP. In exchange for making layout "a bit easier" you will be putting layout logic in the FO Tree. How can it possibly "lead to making layout less complex"? Nor do I see either "the large amount of FO- and LM-specific business logic that AddLMVisitor ends up needing to retain" or why this would be important. Maybe I am missing something here, but when you have no presentation layer and no database, isn't pretty much everything business logic? I guess a case can be made that the presentation layer is the area tree and the data layer is the FOTree. That would make the layout engine the business logic. If that is true, then you are getting ready to take the business logic that is now in layout (where it belongs) and moving it back to the FOTree. Maybe you could start by telling us how someone who insists on a monolithic design even cares where business logic resides. Now, in all honesty, there are other ways (besides the Visitor pattern) to obtain the separation I was seeking. If I had known that the Visitor pattern would be received as being monstrously complex, I think I would have chosen another option, and I have no objection to changing to one of those now. However, this is well-fought territory, and I have no further interest in its outcome. I mention it only to point out the *real* issue in case any real FOP stakeholders are interested. It takes a special kind of logic to deliberately set out to make something less flexible than it was, to reduce the number of options available. However, that is the FOP company line, and I am the one who is out of step with it. FOP's development strategy appears to continue to be wholly staked on the imminent successful release of the new layout system. Anything that is done to reduce the options to only that one must result in the maximum resources being bent toward that goal, right? Is anyone familiar with the economic concept of Unintended Consequences? I don't mean for this to be a rant, nor do I want it to slow anyone down. I just want to make very sure that no one thinks I agree with this stuff, especially when no convincing case has ever been put forth that it is a Good Thing. Victor Mote
