Jeremias Maerki wrote: > I'm slowly getting the impression it may be better if we really totally > modularize FOP (splitting it up into several independently usable > subprojects) so development is only split in the layout field which is > the major problem-child here. But that alone would take long enough and > I can't even imagine how much it will hurt the redesign.
You're on the right track, but I don't know that we need separate subprojects. I am just starting to implement an idea that I have been kicking around for several weeks. I want to create a LayoutStrategy that is either abstract or an interface, and which can be subclassed/implemented by each concrete strategy. We currently have two -- one in the redesign branch, and one in the maintenance branch. The goal would be to eventually drop the maintenance branch layout system into the redesign code as an implementation of LayoutStrategy. It will always be a deficient implementation, but right now it is the best one that we have (else we would be releasing code from the trunk). This would allow us to start releasing code from the trunk, and would unify our efforts in infrastructure, control, FO Tree, Area Tree, etc. This is something we really should do eventually anyway, and IMO it is better to do sooner than later. There are three issues: 1) Some will not like this approach as it seems to draw resources away from the redesign. I'll not reargue this issue again now unless it is needed. In short, nothing is being done on redesign now, so how can it possibly be hurt by anything? Also, eliminating thrashing between two branches will help all of us find resources to work on layout redesign. 2) Some will think that bringing the maintenance branch layout into the redesign will reintroduce the maintenance branch problems. Obviously, this should be avoided, and I think it can be. There are no doubt methods and data which will need to be moved around to get the maintenance branch layout modularized, but it seems possible. 3) It would be helpful to resolve some of our high-level control issues before starting down this path, or at least as part of this project. Moving control of when layout is started, when FO trees are destroyed, etc. up to higher-level objects will be extremely helpful in isolating these subsystems from each other and allowing multiple layout strategies. I see the sequence as follows: 1. Resolve design of, then implement the high-level control changes. This is the Session / Document / Rendering Context issue discussed on the Avalonization wiki, section entitled "Startup Concepts Proposal" at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization 2. Isolate the (existing redesign) layout by forcing all contact with the layout systems to run through the LayoutStrategy. Every layout class except the Stategy implementation becomes non-public (I think). 3. Drop in the maintenance branch layout as an implementation of LayoutStrategy, keeping it isolated as well. Even if this effort is unsuccessful for some reason, or the redesign layout is completed before this can be done, steps one and two above are still needed & useful. I really didn't want to mention any of this until it was done, but I wanted to encourage Jeremias' train of thought. Also, coming to an agreement on steps one and two, and completing them, makes step three much easier. If we can reach a consensus on items 1 and 2, I'll start on them right away. I don't think they are big tasks, but they are pervasive and design-oriented, and I think they require your approval. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
