----- original Nachricht -------- Betreff: Re: RTF and table/column widths - table width attribute Gesendet: Mo 13 Mär 2006 20:39:59 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]>
> On Mar 13, 2006, at 19:53, [EMAIL PROTECTED] wrote: > > Hi, > [...] > I guess, if the RTF renderer --as was already suggested-- needs to > keep its fingers out of the layout package, then the correct way to > go about that --at least, IMO-- would be to have one class in the RTF > package implement the PercentBaseContext interface. An instance of > that class can then be used inside the RTFHandler, and passed back > into the properties subsystem, without having to import anything from > the layout package. I'm doing it exactly in this way, additionally my realization of PercentBaseContext may have a parent, so a table inside a block is rendered with the correct indenting... > > 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: /** * Returns the LengthRangeProperty from left border to right border. Call this * method like * <code>LengthRangeProperty.getOptimum(null)</code> * to have a default length-object. * * @since 0.91 */ 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. > > > In additional this getObject-topic is still open... > > Eclipse's call hierarchy shows these methods are definitely being > used... > > AFAICT, at first glance this seems to be used to cast certain types > of Property instances to generic Objects before re-casting them to > fit the CompoundDatatype interface --the latter cast will definitely > not pass the compilation stage, since Property does not implement > CompoundDatatype (= not all properties are compound properties). What > if the programmer knows beforehand that this cast *will* succeed? The > only viable option seems to be to trick the compiler into believing > that it just might work... Convenient, no? :) 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) in calling the method containing "Object" in it's signature. It makes no sense to me to reprogram the widening conversion and it's not really good programming style to do that much type-guessing and casting. It needs time and is a possible source for runtime errors (ClassCastException...) if not properly used. Maybe the properties should have a getCompoundDatatype-method which may return "null". Let's call it a facade or a factory method. So you the compiler helps you in finding errors (someone calling this facade or factory method and assigning it to the wrong type...). There are two ways in Java to emulate multiple inheritance, either you use multiple interfaces and do some instanceof-checks, I prefer the facade- or factory-pattern. The more common objects has methods to access the less common object or may create a non persistent object, containing the other interface's features. Depends on personal taste (I dislike casting against the direction of abstraction, the other direction is made by the VM). I don't want to teach a how-to-program-lesson, but all my questions are caused by a lack of information in the code/ javadocs. Maybe some other future contributers don't ask that much (sometimes I'm quite annoying) and uncomment some attributes and causing much more damaga than being helpful. Or there's a FOP-cookbook, which I haven't read yet but ought to study, before spamming the dev-list...(You know, what you did, I must understand first, how you thought at this moment, to understand, why the code's done this way to do it the same.) "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025
