Jeremias Maerki wrote:

> The problem with this is really, that the old layout code is scattered
> around in the FO tree (look for layout() methods). The redesign
> introduces the layout managers which is a move to separate the logic
> (layout code) from the data structure (FO tree). The keyword here is SoC
> (Separation of Concerns). These are two completely different design and
> I don't see a chance of properly doing what you propose. The new design
> however really supports plugging in different implementations but I
> don't see an easy way to bring over the old layout code.

I understand the point, but I am still skeptical. Here is what I propose. I
will set up a CVS project on my local machine here that will mimic the real
FOP repository, and go to work on bringing the two branches back together,
completely if possible, but with a bare minimum of branching at any rate.
This will no doubt require some refactoring on the maintenance branch, and
some merging between the branches. At some point, if my head gets too sore
(from pounding it against the wall), I will humbly admit defeat and go to
work on the trunk. A big chunk of this work has to be done eventually
anyway, and IMHO the sooner it gets done the better. For those who think
this is diversion of resources away from the real task, my answer is that I
will probably get up to speed more quickly on the trunk code by doing this
project than by merely reviewing lines of code.

If the committers tell me up front that a successful effort here will not be
considered for commit, and considered reasonably promptly, that would
dissuade me from trying. Otherwise, I think it will be a useful thing both
for the project and for my understanding of it. The worst case scenario for
you guys is that I will learn a little humility, which can't be a bad thing

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to