----- 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

Reply via email to