Re: [VOTE] Properties API

[Joe DeVivo]

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.

Proposal:
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.

Discussion:
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:
+1
Victor Mote