Arved, Obviously, I share many of your attitudes to properties, but I differ in one respect. I think of properties not as rich, but as impoverished. To me, they are just associations of names with values. The richness lies in their treatment in the process of layout, where all of those constraints and interactions will have to be accommodated and resolved in the application of properties to FOs and areas. Interactions, e.g., are inherently "outside" any individual property. Constraints, I have to admit, are generally property-centric, even where they involve testing the value of other properties. This view underlies my attempt to reduce property handling to a set of arrays. I still have an individual (though nested) class for each property, from which commonalities are extracted, while special cases are handled by methods peculiar to the class.
Your concerns (and mine) about the association of build.xml release number and the tag would be resolved by making them identical, or at least deriving the first from the second. If my understanding of the relationship between RCS and CVS is correct, we can do this. Peter Arved Sandstrom wrote: >Hi, Peter > >I personally agree that the properties don't need the XML+XSLT approach. >Even if one leaves aside the aural properties there are over 250 properties, >and on close inspection the commonalities are limited. I believe the largest >group size of properties that are identical is 4. Many properties have extra >constraints (they interoperate with other properties, for example), they >accept different combinations of input generic types, percentages have >meaning only in the context of the property, and so on and so forth. > >One could come up with a super-sophisticated XML+XSLT system to embody all >this, but why bother? > >I'm not going to bad-mouth the current system that FOP has. I acquiesced at >least implicitly in the choice to at least continue with it, at an early >stage. But I now believe that the right place for a lot of logic related to >properties is actually in the properties. I think an XML+XSLT approach >pushes a lot of that out into places where it ought not to be. > >Most of the common handling has actually little to do with the properties >per se - it has to do with expressions and datatypes. This is not the same >thing. An XSL property is not a datatype, IMO, and shouldn't be regarded >that way. > >I don't think it's a pressing issue unless someone then immediately proposes >and moves forward with work to make the properties rich, interesting things. >It's not really an IDE issue - there are IDEs that handle the current FOP >setup just fine. > >I also agree that ease of making changes to properties is not a compelling >argument for XML files, nor for using XSLT to generate the code. The >properties are simply not that similar. So you may as well work on Java >properties files directly. And since properties _are_ what make XSL, if >there are significant changes in properties in the spec then the disruption >is going to be widespread. > >I agree with Keiron's observations regarding the other point, about >versioning. Our numbers are release numbers (major, minor, patch, plus stage >info, as he puts it), and these require human decision-making. You can't >automate release numbers sensibly. > >Anything else Ant supports (timestamping, token filtering, build number >incrementing) makes a lot of sense in the right contexts, mostly in the >sense of configuration management and builds. > >I'd like to see a stronger link between the release number in the build.xml >and the presence of a matching tag in the CVS, myself. I've been personally >guilty of forgetting to tag the CVS when buildng a distro and it's because >there was no mechanism to jog my memory. I don't think the tagging itself >should be automated but some aspect of the source code retrieval prior to >building a dist* target should be dependent on the presence of a matching >tag. Let's face it, right now we have no configuration management at all - >maybe this isn't much better but at least it's something. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
