Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
--- Finn Bock [EMAIL PROTECTED] wrote: I like it. How does this sound: - Unnest Property.Maker to PropertyMaker and put it in fo.properties. - Roll the datatypes classes into their property class and move the property class to fo.properties (but without unnesting their Maker class because the remaining nested Maker classes are really trivial). - Move the handcoded maker classes to fo.properties. regards, finn Fortrinlig Tak nemlig jeres arbejde her ovre! (= Excellent! Thanks for your work here.) Glen (who recommends we stay with English, despite the availability of machine translation... ;) __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
[Glen Mazza] Another option, Finn, is to move all the Property subclasses to fo.properties (even if they're alongside the makers, nested or unnested), after thinking about it, I think that will be a little bit clearer than having them in the datatype package. Comments? I like it. How does this sound: - Unnest Property.Maker to PropertyMaker and put it in fo.properties. - Roll the datatypes classes into their property class and move the property class to fo.properties (but without unnesting their Maker class because the remaining nested Maker classes are really trivial). - Move the handcoded maker classes to fo.properties. regards, finn
Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
On Mon, Jan 26, 2004 at 11:32:22AM -, [EMAIL PROTECTED] wrote:
This patch is intended as inspiration and as an example of the discussion found
here:
http://marc.theaimsgroup.com/?l=fop-devm=107511296910230w=2
The patch includes the following:
- unnests the Property.Maker classes.
- moves the PropertyMakers into properties
- Rolls the datatypes into the property classes.
- Moves the property classes into datatypes.
I have the following considerations:
1. The old situation has pure datatypes, which in theory may be reused
in other situations. In practice, these datatypes are very much
bound to properties, so that reuse is not realistic, and does not
happen in FOP code. Combining the notions of datatype and property
is more tuned to FOP's situation.
2. Even in the old situation the separation between datatypes and
properties is not complete. Compound datatypes contain properties.
3. In code where the datatype aspect is used, the code may become less
logical. This happens in the parsers and in the RTF renderer. An
example from render/rtf/TextAttributesConverter.java:
// Cell background color
ColorTypeProperty colorTypeProp =
(ColorTypeProperty)propertyList.get(Constants.PR_COLOR);
if (colorTypeProp != null) {
ColorTypeProperty colorType = colorTypeProp.getColorType();
if (colorType != null) {
if (colorType.getAlpha() != 0
|| colorType.getRed() != 0
|| colorType.getGreen() != 0
|| colorType.getBlue() != 0) {
rtfAttr.set(
RtfText.ATTR_FONT_COLOR,
convertFOPColorToRTF(colorType));
}
Here colorTypeProp and colorType denote the same, and the code is
not quite logical. That is because the method getColorType now more
acts as an assertion. In the new situation it could be made more
logical as follows:
// Cell background color
ColorTypeProperty colorType =
(ColorTypeProperty)propertyList.get(Constants.PR_COLOR);
if (colorType != null colorType.getColorType() != null) {
if (colorType.getAlpha() != 0
|| colorType.getRed() != 0
|| colorType.getGreen() != 0
|| colorType.getBlue() != 0) {
rtfAttr.set(
RtfText.ATTR_FONT_COLOR,
convertFOPColorToRTF(colorType));
}
Therefore, in the new situation people might want to do some
rewriting.
All in all I think that this change simplifies the code, and would be
a good change.
Allow me to make some notes:
1. Would it not be a good idea to move Property.java from fo to
properties?
2. TableColLength and LinearCombinationLength do not have the word
'Property' in their name. I would advocate making these names
consistent with the others.
3. Should ToBeImplemented.java also be removed?
A lot of good work.
Regards,
Simon Pepping
--
Simon Pepping
home page: http://www.leverkruid.nl
RE: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
-Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] snip / All in all I think that this change simplifies the code, and would be a good change. Allow me to make some notes: 1. Would it not be a good idea to move Property.java from fo to properties? A question that was on the tip of my tongue too... I'd think: not only Property.java, but all related Maker-classes as well. snip / 3. Should ToBeImplemented.java also be removed? In the long run, that *should* be the objective indeed. For the moment, I'd leave that right where it is, until we're sure we've no more refs to it hidden somewhere else in the code. Cheers, Andreas
Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
Simon Pepping wrote: I have the following considerations: 1. The old situation has pure datatypes, which in theory may be reused in other situations. In practice, these datatypes are very much bound to properties, so that reuse is not realistic, and does not happen in FOP code. Combining the notions of datatype and property is more tuned to FOP's situation. Alt-design has completely separate properties and data-types. Instances of datatypes contain int references to the property on which they were defined. 2. Even in the old situation the separation between datatypes and properties is not complete. Compound datatypes contain properties. Alt-design has no compound properties. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
