John Austin wrote:
> 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.
I think we have a one-time cost of changing the interface. IOW, I think any
changes that you make to the way Properties are handled will require changes
to Layout and Render. I just want to make sure that it is handled so that
any future changes can be handled transparently.
> 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.
Yes, that is absolutely true. Or the existing interface can simply become
the back-end to the new one (at least until the implementation changes). All
of that is negotiable as a separate issue.
> > > 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.
I think I must not be following you here. Since properties are logically
attached to FO Object instances, it made sense to me that the methods for
"get"ting them should live there as well. So the 250-380 methods would go (I
think) into FObj and subclasses. If the adapter needs to have a similar
number of methods, which is what I think you are suggesting, that is OK. I
just want to make it clear that the part of this that would be visible to
the rest of FOP would *only* be the stuff in FObj and subclasses.
> What else is needed to 'get' properties ? Your accessors just have the
> property name.
That, of course, depends on the implementation. Right now, they would be
looked up in the PropertyList. However, there are conversions that need to
take place. I am thinking, for example, that lengths should always return a
millipoint value, to simplify Layout and Render.
> > 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.
I understand, and "forced" is too strong a word. However, I think we are all
very, very, VERY eager to help develop new developers. Your observations
about FOP's performance and the causes ring true, and it makes sense to help
make you productive. Three months ago, I would not have been as excited
about this project, because we still had a lot of overlap between FO Tree
and Layout. That has mostly been factored out, and cleaning up the interface
for Properties is IMO a logical extension of that work.
> 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!
As far as the interface to the remainder of FOP goes, I think the signatures
of the accessors is all of it. I can't think of anything else. If I want the
max-width property, I should be able to do something like:
int maxWidth = someFObj.getMaxWidth();
The current implementation might look like this:
public class FObj {
....
public int getMaxWidth() { //WARNING -- unchecked or tested!!
return properties.get("max-width").getLength().getValue();
}
A subclass that doesn't use max-width might override with:
public int getMaxWidth() {
return FObj.INVALID_PROPERTY;
}
A future implementation might have very different internals, but would have
the same signature.
Victor Mote
