Please correct me if I'm wrong, I'm just sort of restating your proposal to make sure I understand it and how it fits in the app. What you're suggesting here is not to abandon the PropertyList, but to encapsulate it by replacing get(name) with getName(). Then we lose the dependency on the HashMap implementation of PropertyList, and we prevent people from thinking they'll get a property back from a FObj that doesn't support that property.

I just want to make sure we're on the same page, especially before I volunteer :)

On Nov 24, 2003, at 6:17 PM, Victor Mote wrote:

FOP Developers:

This has been kicked around recently, but I realized that it may be
beneficial to go ahead and propose a change to get things going. The issue
of how Properties are stored in the FO Tree is in play. Since we now have FO
Tree pretty well isolated, I see some benefits to nailing down an API for it
that should be durable enough to work for any scheme that is used for
storing property values.

I propose that public "get" methods be used to retrieve FO Tree property
values, and that the data behind these values be made as private as
possible. The methods should be given a name based on the XSL-FO Standard.
For example, the "max-width" property should be accessed using the method
"getMaxWidth". The values returned should be the "refined" values.

1. The purpose here is to separate the storage of the property values from
their presentation (API) to the rest of the system. This opens the door for
later changes to the storage without disrupting the remainder of the system.
2. This could perhaps be implemented for now only in FObj (??).
3. This is not directly relevant to the question, but needs to be addressed
from the "big picture" standpoint. With the FO Tree mostly isolated, and
LayoutStrategy implemented, the issue of whether a certain feature is
implemented or not moves from the FO Tree to the specific LayoutStrategy.
Each LayoutStrategy eventually needs to track which objects and properties
it supports. The FO Tree should always store and return the data, without
regard to whether it can be used or not. In the future, our properties.xml
file, "compliance" page, and perhaps other things need to handle this. The
LayoutStrategy needs to be the entity that reports on whether a feature is
supported (perhaps using a scheme similar to properties.xml).
4. If accepted, this would be a great project for one of the new developers
to tackle. I don't mean to volunteer anyone, but it might be a good "feet
wet" project.

My vote:

Victor Mote

Reply via email to