Bojan Smojver wrote: > Terry Steichen wrote: > > >I've tried $int.valueOf($entry.elementAt(0).Price), but that has > > There are no methods Integer.valueOf(Float) nor Integer.valueOf(float) > in JDK.
I was aware of that, but I wondered if $entry.elementAt(0).Price might somehow be automatically returning the toString() result, because the above formulation at least didn't generate any error. However, I think I've figured out what's going on. What to do about it is another thing. As Bojan suspected (and Geir confirmed), the actual float value of $entry.elementAt(0).Price was returned by VelocityContext (via reflection) as a Float. Thus I am able to invoke any of the Float methods on it (floatValue, intValue, toString, etc.). The problem: The *only* type that VTL math directives operate on is int. So, if the price was $2.75, I can extract the price.intValue() as 2, losing the .75. If I extract price as a String (toString()), then I can (laboriously) retrieve all the parts using substring operators (the complexity of which, I suppose, I could hide with a macro). Clearly, everything else being equal, it makes more sense to do all the computations in the Java module, prior to inserting the results into the VelocityContext. However, in this particular case, each object is one of the results of a database query and it would be *enormously* better to leave the retrieved objects in their native form and pick them apart as they are 'opened up' and displayed. Not really sure what to do at this point. Probably have to use use a macro to screw around with the String form (ugh!). Regards, Terry
