----- original Nachricht -------- Betreff: Re: RTF and table/column widths - table width attribute Gesendet: Di 14 Mär 2006 18:25:15 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]>
> On Mar 14, 2006, at 07:43, [EMAIL PROTECTED] wrote: > > > Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > > > >> BTW, dunno if you noticed, but you can pass a null into i.e. > >> LenthRangeProperty.getOptimum() to get to the underlying Property, > >> without the need for a PercentBaseContext... > >> (~ something like: LengthRangeProperty.getOptimum(null).getNumeric > >> ().getValue()?) > > No, I didn't notic this, maybe it should be mentioned in the > > javadocs (which are sometimes a bit short of information). It's not > > obvious to me, that a LengthRangeProperty is a replacement for the > > width-attribute. Maybe the javadoc comment should be something like > > this: > > Good point! I must admit that I stumbled upon this myself (in > LengthRangeProperty.getString()), trying to solve your problem... ;) added to the Todo, to lookup doc-less classes and get some information 'bout it...if it's not easier for the "creator" to commit comments to trunk (answering my questions may result in more text *g*) > > > Additionaly getWidth should be declared deprecated (again the > > compiler helps to find every use of deprecated API...blabla) and > > people like me, sticking to the javadocs, won't ask that much. And > > a bit earlier on this topic it was said, that maybe some features > > from my work, e.g. the parent-attribute of PercentBaseContext- > > realization, may be moved to a more abstract layer. Every > > LayoutManager has a parent (except the root), RTF export needs > > something similar, so why not moving it towards direction of > > abstraction. > > Also a worthwhile suggestion. Don't let us stop you! :) > How 'bout introducing an AbstractPercentBaseContext which already > offers a very basic implementation for some methods? If I do such basic changes I always create an abstract class, 'cause keeping track of the parent, returning the root and so on is that primitive, that real programmers shouldn't be bored with that kind of work *g* > > But a method "getObject" returning "this" is not necessary, every > > class is instanceof Object so you can assign any instance to a > > variable of type "Object" and calling methods like HashMap.put or > > ArrayList.add results (after widening conversion) > > Yes, but this does mean declaring a new local variable to hold the > result, which I suppose the original programmer wanted to avoid (? > guessing here, since I'm not the author... I'm just trying to make > sense of it --maybe there is none :)) Mkay, but if it's not necessary to hold an attribute, than you should think over again the class' associations and leave this one out. If they don't belong together, don't force 'em... > > Anyway, you'd have to go: > > Object o = property; > CompoundDatatype c = (CompoundDatatype) o; No, you don't have to. The property would have a method 'getCompound()' returning a CompoundDatatype. Either it returns this, 'cause it is a CompoundDatatype or it returns a previously set instance (constructor, set-method) or it creates an instance, if necessary (maybe with default types) or even returns 'null' 'cause it's not able to deal with CompoundDatatype. So the only thing you need is a null-check on abstract levels, not a cast or instanceof. It may return a non-null value which maybe this, maybe an attribute, maybe a Singleton, whatever... [...] > > Maybe the properties should have a getCompoundDatatype-method which > > may return "null". > > Now, this would make sense if 50% (or more) of all FO-properties were > compound, but I'm roughly guessing that it's closer to 15% (? widths, > space-*, keep-*... any others). It makes sense to me if only 1% may return a CompoundDatatype, more sense than returning just Object. But this is personal taste. Maybe the design has a weakness and the author assumed, that a CompoundDatatype is more special than a non-compound. But I may also do it the other way around and say, that all Datatypes are compound, while the non-compounds leave out the abstract part. But you're right, that this is no use, if it affects only 15%. [...] > I see. So it is a matter of preference/personal taste? Well, the > point is exactly that this method serves to switch the runtime type > of a Property instance, without having to perform a cast... Still > don't like it? :) ...and maybe this is a design weakness, why should it be possible to switch the type during runtime, you also don't care if a button's listener is the button itself, an action, a frame or nothing at all. Therefore you have interfaces and realizing classes...abstraction counts...maybe the datatype's value should be apart from it's type definition. Like the DnD-mechanism, having different DataFlavor-s and a single "payload" (InputStream). So the "compound" should be an aggregating pattern, a container (class holding different flavors as kind of list) or facade (collection of methods to access different types). So you could use this for the non-compounds, too (realizing only parts of the necessary methods, others return null or raise exceptions, like the Length-interface, having a context-based and a context-less method)... > All I can say is: Feel free to update these as you see fit, and > submit patches. It's what I try to do whenever I 'discover' how a > certain method performs its magic. First of all I'll have to fix that RTF-proportion-thing, but now I'm sure, that I'll stay a while after that. I'm getting used to it and maybe it becomes fun *g* And I won't forget anything, I'm writing some kind of fop-diary, making it easy to remember, what I did the last few days...and what I've found out. Afterall: Having well documented source code makes it easy to render cookbooks and guidelines from it. Sometimes my comments remember me of neet little algorithms, boobie traps and often I start thinking 'bout the whole bunch of lines, if it's really the best way to solve my problems. And it's absolutely necessary, if I share that piece of art with others.
