John Austin wrote: > I just spent a while trying to understand PropertyList > and PropertyListBuilder and found out that I need to > understand Property and Property.Maker as well. I think > I am going to have to help with this part of the project > but it is going to take a while.
Yes, this stuff is a little hard to follow. > I offered (off-line) to look merging the Alt-Design code > in to the main branch but I suspect that there are some > different directions associated with this. Perhaps this > is the reason it has not been done so far. I am still willing > to work on this but I don't want to walk in to a firefight. FWIW, I don't think there is really a firefight. Our discussions are usually at least robust, maybe even rowdy, but AFAICT, there is a large amount of mutual respect. That said, we *are* still trying to sort out some design issues. We currently have three lines of development, and I have made my initial focus an effort to try to get that winnowed down to one as quickly as possible. One of the three is Peter's alt-design. Here is a quick summary, as I understand it (Peter please correct these if wrong -- I'm not trying to misstate your case): 1. improved property handling 2. pull-parsing instead of an FO Tree (but with some data stored in memory) 3. a different layout approach Re #1: there is general agreement that this can be improved, and performance is only one aspect of this. As you have already found, readability is an issue as well. Now that we have the FO Tree stuff in trunk isolated (kind of), we can begin thinking of the FO Tree as a service or a separate product. IOW, it can have its own API "contract" with the rest of FOP. As long as the API remains constant, we can change the mechanical aspects behind it without breaking anything else. Thus my comments yesterday about changing the API first. Re #2: this is the one that I don't yet understand. Peter and I had a thread about six months ago that tried to resolve this, and I think he will respond to this when he has time. Re #3: we have now implemented LayoutStrategy, which means that alternative layout systems can at least theoretically be dropped into FOP. See subsequent announcement for more information on this aspect. The real issue for you John is whether #1 can be separated from #2 within the alt-design stuff. I don't know the answer, since properties to me means "FO Tree" and means something else in alt-design. I would personally be very glad to have you look at the whole thing, being confined neither to the status quo nor to Peter's work (but considering both), and make a recommendation. One of the reasons for the FO Tree isolation work was to make issues like this easier to address -- except for the FO Tree API issues (which should be resolved first), you don't have to worry at all about breaking layout or renderers. Victor Mote
