Response below. > -----Original Message----- > From: J.Pietschmann [mailto:[EMAIL PROTECTED]] > Sent: December 7, 2002 7:16 PM > To: [EMAIL PROTECTED] > Subject: Re: Redesign issues > [ SNIP ] > Now the biggest issue: the layout managers itself. At the first > glance it is > not obvious why they should be first class objects at all, in > particular as > a cursory examination of the code shows a one-to-one correspondence to FOs > both for classes and instances. Well, layout managers abstract the layout > *process*, however, the deep layout manager class hierarchy is > mainly designed > around code reuse, which makes it really hard to understand. > There is a reason > that design rules recommend against overuse of inheritance for > code reuse and > deep inheritance hierarchies. There is only so much someone can > hold in the > brain. Nevertheless, this is something I don't know how to fix on > the cheap.
I actually helped push for this last year - the notion of separate layout managers. I was strongly influenced by the mess that FOP code had become at the time, and really thought that layout should be taken out of the FOs themselves; that the FO's, in a sense, were (or should be) just value objects. I worked on an xslfo-proc prototype (in Perl) for months earlier this year. I started out with the layout manager idea. It became increasingly clear to me that there was in fact a natural 1-1 correspondence between managers and FOs. I had a prototype, incidentally, which properly handled reference-orientation in all regions, and even took RO down to block-containers, something which no implementation (not FOP, not XEP, not XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly, which I don't know. It's also interesting, Joerg, that you should mention a "hard to understand" layout manager class hierarchy...this is also what inevitably developed in my prototype. So at some point (and I think there are comments and emails to support this) I eventually came back to the thought that there is nothing wrong with individual FOs being able to do their own layout. Which is actually the existing "maintenance stream" FOP model. I'll have some more to say later....these are immediate comments. I am just struck by the fact that it is now December 2002 and we are not where we want to be, not even close, which is providing an open-source Extended conformance XSL processor to the hungry, huddled and poor. Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
