Victor, I was mostly backing away from my earlier posting which was
off-target.
On Tue, 2003-11-25 at 13:26, Victor Mote wrote:
> John Austin wrote:
>
> > After thinking about the proposal, I'm not sure it solves anything.
> 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.
In order to adapt Peter's ideas, I would need identify the current
Interface(s). Ideally a re-implementation of Property handling would be
invisible outside of those classes.
All the proposal addresses is the signature of some accessors. It does
not identify the set of property-related classes. I think an adapter
class could convert the current interface to the proposed interface.
This could be useful if it covers the entire properties interface.
> > The discussion favours the proposal.
>
> I don't understand what you are saying here.
All/most other postings agreed with the proposal.
> > 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).
Just a for-instance sketch of an Adapter. Reference to properties has to
come from somewhere. I used Inheritence as a convenience.
> > 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.
What else is needed to 'get' properties ? Your accessors just have the
property name.
> 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,
Don't feel forced. You CAN ignore me. I appreciate your efforts to clue
me in.
> 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.
I support your Interface-view of properties but would like to have the
scope of the Property interface mapped out to include more than the
accessors. Of course, if these accessors and some references all ready
held by FObj, can do the trick, lets get on with it!
--
John Austin <[EMAIL PROTECTED]>
