John Austin wrote: > > 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
I almost misunderstood your point here. I now understand you to be referring to the distinguishing between property A and property B, not the values of the properties themselves. > 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 OK. This is actually the stuff I am trying to hide, so is not entirely relevant to the question at hand, although the purpose of the proposal is to make it easier to do exactly this, or something like it. That said, I wonder why we can't just store these values in fields in the FO object itself. Many of the values are boolean or enumeration types, others are stated or computed lengths, which, in their *refined* terms can be spit out in millipoints. There are some properties which may require non-primitive types, so pointers get stored to them. > > 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 agree. Fonts are a special case -- the Font object will encapsulate the font-family, size, variant, etc. Eventually, a collection of Fonts used will be searched for a match before creating a new Font 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 ? There is a properties.xml file (I think that is the name) that has some of this. > 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 (??). Point 2 is pretty relevant to point 4. What I was saying is that to get this done, it might only require placing the 250 or 400 "get" methods in FObj, for now anyway. > * we don' need no steenking enumeration type! > > For years I thought the 'steenkin badges' quote originated with > WKRP's Dr. Johnny Fever. Could be. I would have guessed Cheech Marin. Victor Mote
