Terry Steichen wrote: > 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).
There have been numerous (funny wording, ha :-) discussions on the Velocity lists about introduction of floating point arithmetic into Velocity. Personally, I'd go for a 'soft' approach where all number are equal, either through being one number type that can hold every value or just being strings, like in a shell. I think it would avoid confusion that designers can ran into with number types other then int. But there are many people that disagree with such approach due to complexity issues and because they believe that floating point numbers have no place in a View of an application. Again, personally, I don't really need floating point in my current apps, so my discussion contribution was more rhetorical than practical. Although I can see cases where there is a Float returned by Java and the View part of the application has to decide how it's going to be displayed. For instance, a balance of some sort can be displayed in red or black, depending on it sign (typical accounting scenario). > 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. Yes. I think it's probably the best approach. Bojan
