John Austin wrote:
> After thinking about the proposal, I'm not sure it solves anything.
Perhaps not. If the purpose of building a house is to supply shelter, then
building a foundation would seem also not to solve anything. However, it is
kind of a necessary first step toward the ultimate goal. All the proposal
attempts to do is to separate the interface from the implementation. Right
now the interface is pretty tightly tied to the implementation. Changes that
you might make to the implementation would require (I think) changes to the
LayoutStrategys and to the Renderers. Also, as Glen has pointed out, there
is business logic that can be pulled out of these code modules back into FO
Tree where they more properly belong, and where duplication and confusion
can be minimized.
> There are two aspects to the redesign of Property handling in FOP.
>
> * Interface means the external points of contact for Property data
> * Interface determines impact of changes on other components of
> the system.
> * Implementation means the internal construction of classes
> * Implementation determines performance characteristics of the
> program.
>
> The discussion favours the proposal.
I don't understand what you are saying here.
> Interface
> The current proposal asks that FOP will employ Java-Bean-like accessors
> for the properties of Formatting Objects visible to the FOTree. As an
> example:
>
> getMaxWidth?() for the property "max-width"
>
> There are between 250 and 380 of these methods required and they could
> be generated automatically from an XML-based list of properties. This
> list could be derived (if not generated) from the XSL-FO Specification
> itself. Some kind of simple adapter class can be used to equate the
> proposed interface to the existing one:
>
> class PropertyAdapter? extends Property{ // Ugh! just f'rinstance
>
> // repeat the following about 380 times:
> final public Property getMaxWidth?() { // use final to inline and annoy
> return get("max-width");
> }
> }
Sorry -- I was not clear here. I meant to suggest that these methods be
added to FObj (and its subclasses to the extent necessary).
> There is no statement defining the current interface. This will be
> determined from existing code.
>
>
> Implementation
> The proposal makes no suggestion for implementation and my earlier
> submission is not relevant except as an indication that this issue is
> linked to performance.
Again, I am not sure what you are saying here. The proposal deliberately
does *not* address implementation. I am quite glad to have you address the
performance aspects of implementation, but I think it is a separate issue
from the interface. We can (and should, IMO) fix the interface before or at
least during any changes to the implementation. All I am trying to do is to
hide the implementation from the rest of the system.
Your earlier submission *is* relevant to implementation side of the
question, just not to the question that I raised, which is totally
interface, and which I consider to be foundational to the changes that you
are contemplating. The changes you are considering would need to conform to
the interface being discussed. Now, if something in my proposal is harmful
to the implementation(s) that you are considering, that is definitely
relevant.
Since FO Tree (and Properties) kind of works right now, we have been paying
much more attention to other parts of the FOP code. Your questions and
interest are forcing us to address it sooner than we would have. Obviously,
one of our highest priorities should be to make other developers as
productive as possible. Also, to a certain extent, we have been waiting on
Peter West's work, hoping that his efforts can be useful in all of this. I
am still hoping to hear from Peter on this, but in the meantime, I am trying
to do some housekeeping that IMO will be important to clear the decks for
you.
Sorry to be so dense -- I may just not be used to your style of writing.
Please let me know if I am missing something.
Victor Mote
