On Mon, 2003-11-24 at 19:47, Victor Mote wrote: > FOP Developers: > > 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.
I have been thinking about this a bit and I would like to throw out a few rambling observations: Properties are defined in the spec, so there are a finite number of them meaning that they map nicely in to an enumeration type*. Peter West had written some stuff along that line. This allows us to get away from object-and-compute-intensive String types. There are about 380 of these in Peter's Mapping. Some 249 are simple attributes and the rest are more complex, like space-after.optimum, space-after.miumum etc. One train of thought I've had asks whether we need an atomic 'Property' type alone or whether we can use a larger aggregate object type like PropertyList that is a vector with each attribute value in a fixed position. The idea here is that such a vector, something like a vTable, can be merged quickly to resolve inheritence. v[FONT_FAMILY] = "sans-serif" v[FONT_SIZE] -> "10pt" v[...] -> ... v has 400 entries or 250 entries and we use polymorphism somehow on the complex properties > 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. We need to contain the number of objects here. say with canonical mapping of the property name strings. Possibly also use canonical mapping of the attribute values too. How many times is "10pt" or "bold" coded in an document ? Especially, given that patterns of FO are emitted by XSLT in other programs. Allows faster compares when we can test with == rather than Object.equals( Object). I had thought that the fact that all of the attributes are in the XSL-FO Specification and that there are some simple structures used, I might want to generate the property name list and some of the acccessors like you have named them, automatically. Is there an XSL Schema for XSL-FO, or would I just extract them from xml in the Spec document ? I can't say anything about how this stuff gets used, points 2 & 3. I'd be interested in being involved in item 4. > 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 * we don' need no steenking enumeration type! For years I thought the 'steenkin badges' quote originated with WKRP's Dr. Johnny Fever. -- John Austin <[EMAIL PROTECTED]>
