You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by ST...@thoughtworks.COM on 2002/10/15 08:06:41 UTC
comparing monetary value
Hi,
I believed at the moment, all numbers are treated as Integer. Anyone
came across this problem of manipulating with money value before?
Example :
Give a certain amount has to be less than a given value.
if ($someMoneyValue < 0.01) ???
How do people normally handle money in velocity?? Thanks.
cheers,
shen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <jr...@terra.es>.
STham@thoughtworks.COM wrote:
>Hi,
>
> I believed at the moment, all numbers are treated as Integer. Anyone
>came across this problem of manipulating with money value before?
>
>Example :
>
> Give a certain amount has to be less than a given value.
>
> if ($someMoneyValue < 0.01) ???
>
>How do people normally handle money in velocity?? Thanks.
>
Apparently, they put some kind of custom "tool" in the context. This
strikes me as quite undesirable really, though it is a necessary
workaround due to VTL's lack of support for decimal numbers.
It's not hard to put in a custom tool, but my view is that something as
basic as decimal arithmetic should just always be there and work in the
same way. It is undesirable for the ability to do decimal arithmetic to
sometimes be there and sometimes not and also to work in different ways
depending on the project you are involved with and what custom tool they
put in there.
Well, I think it is fair to point out that other template engines, such
as FreeMarker, the one I am specifically involved with developing, do
support decimal numbers and decimal arithmetic in the core. In fact, it
also support locale-specific formatting based on the template's locale.
So, 1.23 is output as 1,23 in a european locale, for example.
The syntax is a bit different. You would have to write:
<if someMoneyValue < 0.01>
blah blah
</if>
Anyway, that's information that could be helpful to you.
Best Regards,
Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html
>
>cheers,
>shen
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <re...@wanadoo.es>.
On Thursday 17 October 2002 11:16 am, Martin Jacobson wrote:
> Jonathan Revusky wrote:
> > On Wednesday 16 October 2002 09:44 am, you wrote:
> >>This thread, for all the heat it is generating, surely revolves around
> >>the separation between business logic, and presentation. If you think
> >>that a rigorous separation is a Good Thing, then there seems, on the
> >>present evidence, to be no requirement for Velocity to handle any
> >>numerical values other than integers.
> >
> > Excuse me. What evidence are you referring to?
>
> My own evidence, of course! :-)
<sigh>
Well, when you referred to "evidence", I thought you meant something besides
your own subjective experience. It's certainly a very odd use of the term
"evidence". You know, "evidence" typically means some objective thing that
other people can look at. You know, like in those court-room dramas... the
blood-stained murder weapon etcetera...
When you say "the evidence shows that..." and then, when challenged for what
that evidence is, you say that the "evidence" in question is your own
subjective experience, well... really... some people could even take this as
a sign of intellectual dishonesty. It certainly seems tantamount to just
saying: "It's that way because I say so!"
> I enforce the separation between biz logic (servlet) & presentation (vm)
> rigorously, and have come across no requirement for any arithmetic
> features at all.
Hmm. Okay, but does it logically follow from there that nobody else has a need
for any arithmetic features? Does it even follow logically from there that
you yourself will never, in the future, have a need for such features?
You know, your statement is, AFAICS, almost completely meaningless. That you
don't need a given feature that the tool lacks basically stands to reason,
because, if you did, you presumably would have switched to using something
else, but you haven't....
I mentioned elsewhere the classic statistic inference problem of
"self-selection bias". That operates very strongly in this case. The people
who are long-time users of a tool tend to think (disproportionately) that the
tool in question is feature-complete because they don't need whatever missing
feature. The people who differ mostly vote with their feet, but, as such,
they are not around any more and become unobservable. This is "self-selection
bias".
>
> >>If, on the other hand, you want to
> >>be able to manipulate, eg, monetary values in the template, then
> >>'vanilla' Velocity won't work for you.
> >>
> >>My preference is for rigorous separation - but I can think of
> >>circumstances where the 'quick hack' option of putting calculations, and
> >>numerical comparisons in the presentation layer might make sense. (But
> >>then, I'd use JSPs, to save myself learning Yet Another Programming
> >>Language!)
> >
> > Well, I have to strongly disagree with this. The reason I would not use
> > JSP's is because I think that working with embedded Java constructs is
> > not accessible to a non-programmer. I want a separate team to control
> > presentation with absolutely minimal involvement from myself.
>
> On further reflection, I also disagree with myself! The reason I went to
> Velocity in the first place was to escape from JSPs! However, there's
> more than one way to skin a cat, and extending the template engine to
> handle this kind of thing isn't neccessarily The Right Way
Maybe not, but it is a matter of legitimate technical debate. However, in a
legitimate debate, you can't speak of "evidence" and have the "evidence" be
your own subjective experience which is not observable by anybody else.
>
> Let's take the example you mentioned of calculating the lire equivalent
> of a Euro value: I agree that this is purely a presentation issue, but
> why do I have to do this calculation server-side? Web developers already
> use JavaScript for other purposes (eg, form data validation, fancy
> roll-overs and the like), so why not use that?
They could. However, that's introducing yet another scripting tool into the
mix, which potentially complicates project management considerably.
Also, a templating tool can be used for other things besides web applications.
Is it reasonable to assume that a javascript engine operates on another pass
after the template engine produces its output?
Suppose I'm generating a .ps or .rtf document? Or generating notificatoin
emails?
And besides, plenty of people have javascript turned off in their browsers
(and certainly email clients) for security reasons. In general, I would say
that it's an axiom of application development for the web that the fancier
the client-side technology you use, the more you limit your potential
audience. (And that's a trade-off of course...)
> To illustrate:
> <html>
> <head>
> <title>Testing embedded JavaScript</title>
> <script language="JavaScript">
> function showLire(euros)
> {
> document.write(euros * 1936);
> }
> </script>
> </head>
> <body>
> <p>1 Euro =
> <script language="JavaScript>
> showLire(1);
> </script>
> Lire
> </p>
> </body>
> </html>
>
> This puts the presentation logic in the presentation layer, where it
> belongs, using a presentation language that the designers already know,
> and doesn't waste server processor cycles on a problem that the client
> is perfectly capable of solving.
Martin, are you maintaining a visual image in your mind of what we are talking
about?
The specific case of converting a price in euros to lire: do you think that
the server-side CPU cycles that this would expend are significant? Is this a
reasonable point or are you just fishing around for any objection?
> Velocity's minimalism is its greatest strength, as it makes it easy for
> the Web designer to learn and use: let's keep it that way! (KISS)
Well, Martin, your proposed workaround for not having the decimal support in
Velocity is that this should be handled in javascript and this implies that
the template author necessarily masters javascript as well. You introduce
another scripting language into the equation and then you invoke minimalism
and KISS at the end.
Is this not a rather strange contradiction? You might think about that.
Regards,
Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, October 17, 2002, 11:16:39 AM, Martin Jacobson wrote:
> Jonathan Revusky wrote:
>
>> Excuse me. What evidence are you referring to?
>
> My own evidence, of course! :-)
> I enforce the separation between biz logic (servlet) & presentation (vm)
> rigorously, and have come across no requirement for any arithmetic
> features at all.
[snip]
an later you are saying...
[snip]
> Let's take the example you mentioned of calculating the lire equivalent
> of a Euro value: I agree that this is purely a presentation issue, but
> why do I have to do this calculation server-side? Web developers already
> use JavaScript for other purposes (eg, form data validation, fancy
> roll-overs and the like), so why not use that?
> To illustrate:
> <html>
> <head>
> <title>Testing embedded JavaScript</title>
> <script language="JavaScript">
> function showLire(euros)
> {
> document.write(euros * 1936);
> }
> </script>
[snip]
> This puts the presentation logic in the presentation layer, where it
> belongs, using a presentation language that the designers already know,
[snip]
??? Earlier you said that you don't want arithmetic, because that
would weak separation between biz logic & presentation. But now you
are saying that the above task should be solved by the designers
(since it is a presentation layer thing), but they should use
JavaScript. So what??? In this case (JavaScript) you don't feel that
you break businessLogic-peresentation separation, but when a designer
solves exactly the same task with Velocity then you feel that? Does it
make sense?
And now I will not discuss the obvious disadvantage of relying on
client-side JavaScript. In general, the more task you can solve on the
server side, the more reliable your site is. (You know how stupid
browsers can be... and you can't even notice problems. If something
wrong on the server side, at least you have chance to notice that when
you look at the log file.)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Martin Jacobson <ma...@libero.it>.
Jonathan Revusky wrote:
> On Wednesday 16 October 2002 09:44 am, you wrote:
>>This thread, for all the heat it is generating, surely revolves around
>>the separation between business logic, and presentation. If you think
>>that a rigorous separation is a Good Thing, then there seems, on the
>>present evidence, to be no requirement for Velocity to handle any
>>numerical values other than integers.
>>
>
> Excuse me. What evidence are you referring to?
My own evidence, of course! :-)
I enforce the separation between biz logic (servlet) & presentation (vm)
rigorously, and have come across no requirement for any arithmetic
features at all.
>
>>If, on the other hand, you want to
>>be able to manipulate, eg, monetary values in the template, then
>>'vanilla' Velocity won't work for you.
>>
>>My preference is for rigorous separation - but I can think of
>>circumstances where the 'quick hack' option of putting calculations, and
>>numerical comparisons in the presentation layer might make sense. (But
>>then, I'd use JSPs, to save myself learning Yet Another Programming
>>Language!)
>>
>
> Well, I have to strongly disagree with this. The reason I would not use JSP's
> is because I think that working with embedded Java constructs is not
> accessible to a non-programmer. I want a separate team to control
> presentation with absolutely minimal involvement from myself.
On further reflection, I also disagree with myself! The reason I went to
Velocity in the first place was to escape from JSPs! However, there's
more than one way to skin a cat, and extending the template engine to
handle this kind of thing isn't neccessarily The Right Way.
Let's take the example you mentioned of calculating the lire equivalent
of a Euro value: I agree that this is purely a presentation issue, but
why do I have to do this calculation server-side? Web developers already
use JavaScript for other purposes (eg, form data validation, fancy
roll-overs and the like), so why not use that?
To illustrate:
<html>
<head>
<title>Testing embedded JavaScript</title>
<script language="JavaScript">
function showLire(euros)
{
document.write(euros * 1936);
}
</script>
</head>
<body>
<p>1 Euro =
<script language="JavaScript>
showLire(1);
</script>
Lire
</p>
</body>
</html>
This puts the presentation logic in the presentation layer, where it
belongs, using a presentation language that the designers already know,
and doesn't waste server processor cycles on a problem that the client
is perfectly capable of solving.
Velocity's minimalism is its greatest strength, as it makes it easy for
the Web designer to learn and use: let's keep it that way! (KISS)
Martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <jr...@terra.es>.
On Wednesday 16 October 2002 09:44 am, you wrote:
> STham@thoughtworks.COM wrote:
> > Hi,
> >
> > I believed at the moment, all numbers are treated as Integer. Anyone
> > came across this problem of manipulating with money value before?
> >
> > Example :
> >
> > Give a certain amount has to be less than a given value.
> >
> > if ($someMoneyValue < 0.01) ???
> >
> > How do people normally handle money in velocity?? Thanks.
>
> This thread, for all the heat it is generating, surely revolves around
> the separation between business logic, and presentation. If you think
> that a rigorous separation is a Good Thing, then there seems, on the
> present evidence, to be no requirement for Velocity to handle any
> numerical values other than integers.
Excuse me. What evidence are you referring to? In my various excursions onto
this list, I observe that people are constantly running into the issue of
Velocity's limited support for numerical operations. As for this having to do
with the separation between business logic and presentation, it is not at all
clear to me that this is a cogent argument at all. Surely it is better for
the view layer to handle the correct display of floating point numbers for
various locales transparently. This is very clearly a display issue that can
and should be profitably separated away from the underlying business logic.
But what also I've observed here is that this whole "model-view
separation" mantra seems to have become a closed self-referential system of
thought.
Here are the logical steps.
1. Velocity is a tool with a feature set designed to support a "rigorous MVC
separation":
2. A user shows up on the mailing list complaining that he can't do what he
wants to do (at least without clumsy non-standard workarounds).
3. User is told basically to see point 1. above. You see, the user is not
doing "proper MVC" so Velocity does not support what he wants to do. User
should maintain a "proper MVC separation", right?
But here's the crux of it. How do we know that the user is not doing "proper
MVC"? Well, it stands to reason. If he needs a feature that Velocity does not
have, it must be because he's not doing proper MVC. Otherwise, he wouldn't
find Velocity's feature set inadequate.
And what this boils down to is that if anybody finds Velocity to be missing
features, it is not because of any deficiency in Velocity, it is necessarily
because of a deficiency in their own app! (It's not following proper MVC
separation.)
Anyway, you get the idea, I'm sure. Surely you recognize the classic
"beg-the-question" fallacy taking form in the above?
You know, really, as a friendly suggestion, I think it would be better for
you fellows to refocus any discussion of whether a feature is desirable away
from: "Is this proper MVC?" and towards "Is this idea generally useful?"
With such a refocus, there would be much better possibilities of making some
forward progress.
> If, on the other hand, you want to
> be able to manipulate, eg, monetary values in the template, then
> 'vanilla' Velocity won't work for you.
>
> My preference is for rigorous separation - but I can think of
> circumstances where the 'quick hack' option of putting calculations, and
> numerical comparisons in the presentation layer might make sense. (But
> then, I'd use JSPs, to save myself learning Yet Another Programming
> Language!)
Well, I have to strongly disagree with this. The reason I would not use JSP's
is because I think that working with embedded Java constructs is not
accessible to a non-programmer. I want a separate team to control
presentation with absolutely minimal involvement from myself.
That is precisely why I would not want a situation, where, in order to
display a distance in miles as well as kilometres (because this requires
multiplication by a non-integer) I have to become involved. I don't know how
you value your time, but I would not consider this to be a good usage of my
time, or of developer resources in general.
In fact, in terms of constant units conversion, this is quite clearly a
presentation issue. For example, in terms of straight business logic, there
is currently no difference between Euros and lire. The lire all became euros
and the lire ceased to exist. It only exists in people's minds. The same is
true of deutsche-marks, francs, and so on.
There is no reason for lire to exist in the business logic. It's all euros.
If lire are offered, it is a purely presentational convenience for people.
In any case, stepping back from this a bit, does it not really verge on the
absurd to suggest that multiplying a number by a constant is something that
should require programmer intervention?
Regards,
Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Daniel Dekany <dd...@freemail.hu>.
Wednesday, October 16, 2002, 9:44:17 AM, Martin Jacobson wrote:
> STham@thoughtworks.COM wrote:
>> Hi,
>>
>> I believed at the moment, all numbers are treated as Integer. Anyone
>> came across this problem of manipulating with money value before?
>>
>> Example :
>>
>> Give a certain amount has to be less than a given value.
>>
>> if ($someMoneyValue < 0.01) ???
>>
>> How do people normally handle money in velocity?? Thanks.
>>
>
> This thread, for all the heat it is generating, surely revolves around
> the separation between business logic, and presentation. If you think
> that a rigorous separation is a Good Thing, then there seems, on the
> present evidence, to be no requirement for Velocity to handle any
> numerical values other than integers. If, on the other hand, you want to
> be able to manipulate, eg, monetary values in the template, then
> 'vanilla' Velocity won't work for you.
I guess we have already seen that sometimes you need decimal values in
representation tasks (money...). The list-readers who don't want
decimals also admit this when they show workarounds like valueInCents.
Why is it better to force designers (and programmers) to play with
$valueInCents+tools, than simply providing decimal support? Why is it
less error prone and nicer to complicate things with those multiplied
values (force designers to always keep in mind, that what is 10.25 in
real-world, is 1025 here...), than simply use decimals? Does it make
sense?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Denis <ji...@respublica.fr>.
On Wednesday, October 16, 2002, at 08:44 am, Martin Jacobson wrote:
> STham@thoughtworks.COM wrote:
>
>> Hi,
>> I believed at the moment, all numbers are treated as Integer.
>> Anyone
>> came across this problem of manipulating with money value before?
>> Example :
>> Give a certain amount has to be less than a given value.
>> if ($someMoneyValue < 0.01) ???
>> How do people normally handle money in velocity?? Thanks.
>
>
> This thread, for all the heat it is generating, surely revolves
> around the separation between business logic, and presentation. If
> you think that a rigorous separation is a Good Thing, then there
> seems, on the present evidence, to be no requirement for Velocity
> to handle any numerical values other than integers. If, on the
> other hand, you want to be able to manipulate, eg, monetary values
> in the template, then 'vanilla' Velocity won't work for you.
Even without manipulating floating point values, it would be nice
to have a _standard_ tool in Velocity to format integers as a
currency.
E.g.
#set ($valueInCents = 249)
$currency.dollar(valueInCents)
-> $ 2.49
In fact it could even be done with a macro...
#macro (dollar $valueInCents)
#set( $dollars = $valueInCents / 100 )
#set( $cents1 = $valueInCents % 100 / 10 )
#set( $cents2 = $valueInCents % 10 )
$ ${dollars}.${cents1}${cents2}##
#end
#dollar(249)
-> $ 2.49
Sorry for thinking out loud... We don't really need a standard tool
for currencies.
Is there a good place where to find Velocimacro libraries, so I
don't have to invent things again?
Cheers,
-- Denis.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Martin Jacobson <ma...@libero.it>.
STham@thoughtworks.COM wrote:
> Hi,
>
> I believed at the moment, all numbers are treated as Integer. Anyone
> came across this problem of manipulating with money value before?
>
> Example :
>
> Give a certain amount has to be less than a given value.
>
> if ($someMoneyValue < 0.01) ???
>
> How do people normally handle money in velocity?? Thanks.
>
This thread, for all the heat it is generating, surely revolves around
the separation between business logic, and presentation. If you think
that a rigorous separation is a Good Thing, then there seems, on the
present evidence, to be no requirement for Velocity to handle any
numerical values other than integers. If, on the other hand, you want to
be able to manipulate, eg, monetary values in the template, then
'vanilla' Velocity won't work for you.
My preference is for rigorous separation - but I can think of
circumstances where the 'quick hack' option of putting calculations, and
numerical comparisons in the presentation layer might make sense. (But
then, I'd use JSPs, to save myself learning Yet Another Programming
Language!)
Just my $0.02
Martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Denis <ji...@respublica.fr>.
On Tuesday, October 15, 2002, at 08:32 am, Konstantin Priblouda wrote:
>
> --- STham@thoughtworks.COM wrote:
>>
>> Hi,
>>
>> I believed at the moment, all numbers are treated
>> as Integer. Anyone
>> came across this problem of manipulating with money
>> value before?
>>
>> Example :
>>
>> Give a certain amount has to be less than a given
>> value.
>>
>> if ($someMoneyValue < 0.01) ???
>>
>> How do people normally handle money in velocity??
>> Thanks.
>>
>> cheers,
>> shen
> AFAIK, velocity does not support comparisons on
> anything but integers. I worked around by providing
> convenience methods in my model beans.
> You may also create "comparator" bean, which will
> floats for you
> i.e:
> public class Foo {
> public boolean lessThan(float a, float b) {
> return a < b;
> }
> }
The class Double already has the necessary hooks. If $number is a
Double, you can use:
#if ($number.compareTo($number.parseDouble("0.01")) < 0)
-- Denis.
>
> then in velocity template:
> #if( $Foo.lessThan(a,0.01)
>
>
> regards,
>
> =====
> Konstantin Priblouda ( ko5tik ) Freelance Software developer
> < http://www.pribluda.de > < play java games -> http://www.yook.de >
> < render charts online -> http://www.pribluda.de/povray/ >
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Konstantin Priblouda <kp...@yahoo.com>.
--- STham@thoughtworks.COM wrote:
>
> Hi,
>
> I believed at the moment, all numbers are treated
> as Integer. Anyone
> came across this problem of manipulating with money
> value before?
>
> Example :
>
> Give a certain amount has to be less than a given
> value.
>
> if ($someMoneyValue < 0.01) ???
>
> How do people normally handle money in velocity??
> Thanks.
>
> cheers,
> shen
AFAIK, velocity does not support comparisons on
anything but integers. I worked around by providing
convenience methods in my model beans.
You may also create "comparator" bean, which will
floats for you
i.e:
public class Foo {
public boolean lessThan(float a, float b) {
return a < b;
}
}
then in velocity template:
#if( $Foo.lessThan(a,0.01)
regards,
=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <re...@wanadoo.es>.
On Wednesday 16 October 2002 05:03 pm, Christoph.Reck@dlr.de wrote:
> I'm +1 for float or double support with velocity operators.
>
> In the case of currencies, it would be simple to add a macro
> like:
> #macro( local_currency $currencyCode $price )
> ## ensure that the localy used variables do not conflict with any
> globals ## (in this case we could have used #local() - without parameters)
> #local( $factor $currency $currencyStr $fraction )
> ## do something smart here to convert the $currencyCode to a factor...
> #set( $conversionRate = 1.95583 )
> ## ensure $price is in a floating point format using the
> Double.valueOf() method ## properly round the 3rd digit after the comma
> #set( $currency = ( $conversionRate *
> $conversionRate.valueOf("$price") ) + 0.005 ) ## ensure the string
> representation has at least two traling zeros #set( $currencyStr =
> "${currency}00"
> ## get the last index of the fraction digits
> #set( $fraction = $currencyStr.indexOf('.') + 3 )
> ## emit the new string
> #text( "$currencyCode $currencyStr.substring(0, $fraction)" )
> #end
> #end
Still seems rather tortuous. In FreeMarker, you could just write:
DEM #{1.95583 * priceInEuros ; m2M2}
The m2M2 thingy is saying to use a minimum and maximum of 2 digits after the
decimal. (i.e. exactly 2 digits.)
The resulting output would be something like
DEM 11.79
or
DEM 11,79
depending on the page's locale setting.
Well, to make sure you had the write display, you could go:
<setting locale="de_DE">
Der Preis ist: DEM #{1.95583 * priceInEuros ; m2M2}
>
> then:
> #local_currency( 'DEM' 6.03 )
> emits:
> DEM 11.79
>
> The above macro would work if there would be:
> 1. float support
> 2. a dircetive called #local(...)
> 3. a simple #text macro that does not emit surrounding whitespace.
> 4. and whitespace gobbling would work properly
:-)
This reminds of a saying: "Damn! If I had some ham, I could have a ham
sandwich -- if I had some bread."
Grüssen,
Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Ch...@dlr.de.
I'm +1 for float or double support with velocity operators.
In the case of currencies, it would be simple to add a macro
like:
#macro( local_currency $currencyCode $price )
## ensure that the localy used variables do not conflict with any globals
## (in this case we could have used #local() - without parameters)
#local( $factor $currency $currencyStr $fraction )
## do something smart here to convert the $currencyCode to a factor...
#set( $conversionRate = 1.95583 )
## ensure $price is in a floating point format using the Double.valueOf() method
## properly round the 3rd digit after the comma
#set( $currency = ( $conversionRate * $conversionRate.valueOf("$price") ) + 0.005 )
## ensure the string representation has at least two traling zeros
#set( $currencyStr = "${currency}00"
## get the last index of the fraction digits
#set( $fraction = $currencyStr.indexOf('.') + 3 )
## emit the new string
#text( "$currencyCode $currencyStr.substring(0, $fraction)" )
#end
#end
then:
#local_currency( 'DEM' 6.03 )
emits:
DEM 11.79
The above macro would work if there would be:
1. float support
2. a dircetive called #local(...)
3. a simple #text macro that does not emit surrounding whitespace.
4. and whitespace gobbling would work properly
Tim Colson wrote:
> Jonathan wrote:
>
>>So, instead of simply having:
>>The price is: $price euros.
>>The price is: $price euros. (${price*6.556 FFR)
>>What you seem to be implying is
>>that the non-technical people who want to introduce this
>>change should have to talk to the programmers so that they expose the
>
> constant
>
>>in the template.
>>For some reason, it is "bad" (TM) for them to write 6.556
>>literally in the template.
>
>
> I do not assume 'implied things' since that puts words in peoples
> mouths.
>
> So, I will explicitly say that I personally would indeed expect a
> non-technical designer to ask the Developer for this feature, rather
> than hack it in directly because the template system made it possible.
>
> "some reason": I can propose several reasons why this situation could be
> bad in my opinion:
> 1) the conversion rate changes tomorrow to 5.998
>
> 2) each user has customized preferences for selecting her preferred
> alternative currency (FFR, DM, USD, etc.)
>
> 3) the result of $price * $conversionRate will still need to have the
> correct rounding and formatting for the resulting currency. (Ex. DM 6,03
> or $6.03 USD - not $6.0029999987 DM)
>
> Summary: my solution, using Velocity, would be to do this work in the
> controller and give the template designer simply $price and
> $preferredLocalPrice.
>
> Cheers,
> Tim
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Mike Williams <md...@bigfoot.com>.
>>> On Thu, 17 Oct 2002 00:39:04 +0200,
>>> "Jonathan" == Jonathan Revusky <re...@wanadoo.es> wrote:
>> So, by my count, the current talley of folks who want Velocity to handle
>> non-integer arithmetic operations out of the box:
>> +1 Jonathan
Jonathan> Oh no, not me. I would just as soon have Velocity continue
Jonathan> without support for decimal numbers.
It's amazing that you keep harping on about it in this forum, then.
Jonathan> Look, I don't have a hidden agenda particularly. I've put a lot
Jonathan> of work into making FreeMarker a superior templating solution
Jonathan> and I want people to be aware of it.
You're certainly entitled to that opinion, but I consider it extremely
impolite (to say the least) that you're using this list as your soapbox.
Jonathan> If certain people want hamburgers and you have chosen not to
Jonathan> serve hamburgers in your restaurant ... I don't see what the
Jonathan> issue is in terms of telling somebody that there's a Burger
Jonathan> King round the corner
I'm pretty sure that if you started handing around Burger King flyers in
your local vegetarian restaurant, it wouldn't be well received.
--
cheers, Mike
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <jr...@terra.es>.
Geir Magnusson Jr. wrote:
>On 10/16/02 6:39 PM, "Jonathan Revusky" <re...@wanadoo.es> wrote:
>
>
>
>>My agenda? Well, I want people in that spot to know about FreeMarker as well.
>>It's simple. If the Velocity developers consciously choose not to support
>>decimal arithmetic, I don' t see what the issue is in telling people about
>>FreeMarker -- which does support decimal arithmetic, and has a culture which
>>makes it far more likely that we will add features that people need to get
>>their work done.
>>
>>
>
>Thanks. We all know about Freemarker now.
>
Geir, you seem to have reverted to the "royal we". Is that from being in
close proximity to the British royal family?
Remember, you can only legitimately speak for yourself.
Ciao,
Jonathan
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 10/16/02 6:39 PM, "Jonathan Revusky" <re...@wanadoo.es> wrote:
>
> My agenda? Well, I want people in that spot to know about FreeMarker as well.
> It's simple. If the Velocity developers consciously choose not to support
> decimal arithmetic, I don' t see what the issue is in telling people about
> FreeMarker -- which does support decimal arithmetic, and has a culture which
> makes it far more likely that we will add features that people need to get
> their work done.
Thanks. We all know about Freemarker now.
--
Geir Magnusson Jr.
geirm@adeptra.com +1-203-355-2219 (w)
Adeptra Inc. +1-203-247-1713 (m)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <re...@wanadoo.es>.
On Wednesday 16 October 2002 09:19 pm, Tim Colson wrote:
> Hey gang -
>
> Jonathan accused:
> > You do seem to be deliberately missing the point.
>
> At least I'm not deliberately beating a dead horse. <grin>
> Anyway, I'll skip the baiting comments and focus on these two:
>
> Jonathon posed:
> > Velocity simply does not provide a solution for the localized
> > (or even non-localized) display of decimal numbers.
> > Whether it should do so is open to debate,
> > but it mostly clearly does not address the issue.
>
> Ok - I'll agree to both of those, keeping in mind that while Velocity
> does not provide this OOTB (Out of the Box), it can indeed be
> accomplished by writing a simple drop-in tool.
Well, how simple is it? Actually, in another part of this thread, people are
emphasizing how difficult it is to deal with floating point correctly
(rounding and display issues) as an explanation for why it is not supported.
So there's a real contradiction here.
It certainly seems that it is complex enough that it is highly desirable for a
template engine to address this kind of thing in a standard way. Besides,
even abstracting away whatever tricky implementation issues there are, it's
just plain annoying to have to write something like:
$myCustomTool.multiply($x, $y)
when this could be written:
${x*y}
>
> Personally, I'm happy with current functionality because I mostly push
> all comparisons into the controller. Heck, I currently think any
> comparisons except for "truth" is a slippery slope. Go ahead and call me
> a Luddite, but I prefer simple, and I might even propose the removal of
> Integer comparisons. Hah! ;-)
Oh, go ahead. I'd love that. :-)
>
> So, by my count, the current talley of folks who want Velocity to handle
> non-integer arithmetic operations out of the box:
> +1 Jonathan
Oh no, not me. I would just as soon have Velocity continue without support for
decimal numbers.
> +1 Daniel
> +1 Christoph
Well, c'mon. I'm sure there are lots more people than that who want Velocity
to support decimal numbers. A lot of people wouldn't pipe up and say it
because:
(a) They don't want to be on the receiving end of any browbeating
and/or
(b) They're not in the mood to be treated to the "model-view separation" song
and dance one more time.
Also, a lot of people have surely tried to use Velocity and subsequently
switched to something else because they got tired of these kinds of
limitations. And, almost certainly, the lack of full numerical support was
top of the list. Of course, one will not hear from those people because
they're not around any more. (In statistical inference, IIRC, this phenomenon
is called "self-selection bias".)
> -1 Tim
>
> Note: seems fair to disclose that Jonathan, to paraphrase the FreeMarker
> website, "rewrote the core of FreeMarker".
Tim, when you say it "seems fair to disclose..." somebody could infer that I
have been trying to hide this. As a matter of fact, anybody would very
quickly hit upon the above information by following the link in my sig. I
have been quite up-front about disclosing this.
> Also, I noticed that Daniel
> is heavily active on the FM-DEV list.
That is quite true. But I don't know what you should conclude from that. I
have noticed that various individuals are subscribed to this list as well as
Freemarker-devel. Probably some of them are also subscribed to the webmacro
list as well. Probably they just want to keep up with what is going on in
this space.
Anyway, I referred in a separate message to the "beg the question" fallacy. I
get the feeling now that that you are drifting more towards the "ad hominem
fallacy". That's where, rather than addressing the argument and facts a
person is presenting, you attack the person himself, or impugn his motives...
-- of course, typically the ad hominem fallacy is resorted to because of an
inability to refute the other guy's argument.
> It puzzles me, but I will not
> speculate on why these gents are so worked up about having this feature
> in Velocity, since by Jonathan's own explanation, it already exists in
> the Freemarker template engine which both chaps seem to prefer.
Well, as I said, I would just as soon that the Velocity people never implement
decimal arithmetic.
Look, I don't have a hidden agenda particularly. I've put a lot of work into
making FreeMarker a superior templating solution and I want people to be
aware of it. Now, what is going on here is that I'm sure that a lot of people
try Velocity (after all, it has a really high profile being part of
apache.org) and then after a while, many of these people stop using it
because they run into the tool's limitations and also this "pure MVC"
"rigorous separation" "elegant minimalism" song and dance.
The normal thing for these people to do is probably to revert to using JSP,
since that is the other presentation solution in this space they will know
about.
My agenda? Well, I want people in that spot to know about FreeMarker as well.
It's simple. If the Velocity developers consciously choose not to support
decimal arithmetic, I don' t see what the issue is in telling people about
FreeMarker -- which does support decimal arithmetic, and has a culture which
makes it far more likely that we will add features that people need to get
their work done.
If certain people want hamburgers and you have chosen not to serve hamburgers
in your restaurant, because you believe hamburgers are a bad thing (and maybe
you're right, but it's irrelevant because the customer still wants his
burger) I don't see what the issue is in terms of telling somebody that
there's a Burger King round the corner where they can get what they want.
Anyway, it's all consummately fair. People can compare the various tools and
make their own decision.
Regards,
Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <re...@wanadoo.es>.
On Thursday 17 October 2002 05:23 am, Daniel Dekany wrote:
> Thursday, October 17, 2002, 2:22:14 AM, Geir Magnusson Jr. wrote:
> > On 10/16/02 3:19 PM, "Tim Colson" <tc...@cisco.com> wrote:
> >> Note: seems fair to disclose that Jonathan, to paraphrase the FreeMarker
> >> website, "rewrote the core of FreeMarker". Also, I noticed that Daniel
> >> is heavily active on the FM-DEV list. It puzzles me, but I will not
> >> speculate on why these gents are so worked up about having this feature
> >> in Velocity, since by Jonathan's own explanation, it already exists in
> >> the Freemarker template engine which both chaps seem to prefer.
> >
> > Yes, I too wonder why Jonathan and Daniel are so worked up about this.
>
> <OT>
> Could you please stop this "Jonathan and Daniel" thing... It such a
> waffle. If someone wonder, I tell you why I'm here: Simply, I heard
> that Jonathan is here, and I was Velocity list reader in the pre-FM
> 2.x times, and I was curious what will happen now. And I just can't
> stop myself to reply when I see something nonsense. It has nothing to
> do with the fact that I'm involved in FM. What's then? I don't get
> payment for FM users...
> </OT>
>
> So... returning to the essence...
>
> I don't understand why are you so reluctant about decimals. (Well,
> frankly, I have an idea, but I don't tell it again.) What are your
> counter arguments? (I ask you because you are the leader developer
> here, AFAIK.)
>
> To prevent needles communication, here are a few counter-arguments,
> and why are they invalid (IMO). I don't say here that you say these
> counter-arguments.
>
> 1.
> - Decimals inherently problematic because of the rounding
> complications (1.49999999999999 and such things).
> - Yes, but decimals are existing in the real-life. Is this a good
> logic when someone does not solve something because the solution is
> not trivial? Obviously it does not make sense. Also, exactly because
> it is not a trivial topic, it is better if Velocity solves this, than
> leave individuals to develop tools for it.
>
> 2.
> - It would complicate/distort the syntax.
> - I don't think so. The only point where it touches the syntax is that
> you can write constants like 1.5. But it is just a little extension of
> the syntax, right? Also, it is such an obvious thing.
>
> 3.
> - It would complicate/distort the semantic.
> - From the viewpoint of designer it would *simplify* the semantic.
> Everyday people find it natural that he can use decimals. Integers and
> decimals are not separated so strictly in the brain of non-programmer.
> They are just all numbers. What they don't find natural is that
> 90/100=0 (since it is nonsense), or that they can't compare two
> numbers, because one of them is not integer.
>
> 4.
> - Velocity should solve number formatting then.
> - It is cleanly an MVC view task, right? So it is the task of
> Velocity. Anyway, you must solve it, wether you like it or not, and
> now you are forced to solve it with custom tools. Not to mention that
> number formatting issues are existing even if you support integers
> only (e.g. someone may use grouping when display integers.) A standard
> tool is a possible solution.
>
> 5.
> - We just discuss that we will develop a standard tool...
> - That's OK for solving the formatting problem, but in fact it has
> nothing to do with the question (i.e. supporting decimals or not).
> Operators still will not work (90/100 = 0, relational operators don't
> work...). I know, you can use tools for do these things, but this in
> itself is not a counter-argument... maybe you can say that it makes
> decimals +0 in this field. However, I would disagree then: would not
> it be much better if 1/2 is simply 0.5?
Well, you see, the people who think that 1/2 is 0.5 do not understand
model-view separation properly. ;-)
>
> 6.
> - Designers needs only integers
> - I don't think so, but that's a somewhat subjective question. Also, I
> guess the number of requests means that it is not that uncommon thing
> that someone need decimals. But even if they need it 1 times per 1000
> year (I doubt), in itself it is again a +0 argument.
>
>
> So the main point is that simply I don't see a reason *against*
> decimals (while I and many other uses see reasons *for* decimals). Why
> would be that harmful?
>
> So, what are your *counter-arguments* against decimals?
I doubt you'll get an answer, Daniel.
I hate to be the one to break it to you, but it looks like the debate is over.
The war is over. We won... :-)
This is demonstrated by all the people coming out of the woodwork telling us
to shut up -- while making absolutely no attempt to answer any of these
points on a technical level.
It's pretty sad really... :-(
Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: comparing monetary value
Posted by Rex Madden <re...@precision-distribution.com>.
I use a money object to do comparisons:
http://www.martinfowler.com/isa/money.html
To summarize the article, I wrap a big decimal in a class that can do
addition, subtraction, change currencies, and print out in a sensible
format ($2.99).
For comparisons, you have a method like this:
class Money...
public boolean greaterThan(Money other) {
return (compareTo(other) > 0);
}
Anyway, that's my solution.
-----Original Message-----
From: Peter Romianowski [mailto:megapero@gmx.de]
Sent: Thursday, October 17, 2002 10:57 AM
To: 'Velocity Users List'; 'Daniel Dekany'
Subject: RE: comparing monetary value
Just to end this thread, could one of the developers answer this
(very constructive) mail (I mean the one from Daniel) in *detail*.
I would love to use decimals too and I don't see why people deny that,
BUT nevertheless I love Velocity and I would *really*, I mean like
*desperately really* :), know why there are no decimals but only
integers supported. The number-formatting-feature is not the point,
that should be done by a tool.
Simply put, why is #if ($myIQ < 42.5) BAD? I know the answers are in
this and that mail, but please give me a simple single sentence starting
with "Velocity does not support decimals, because ...". I already
realized (partly the hard way :) that you will not implement decimals.
I will not switch over to another template engine, because Velocity's
simple design *rocks* (note: no contradiction here), although some
development could be done (decimals, macros, perhaps
whitespace-gobbling).
I would like to end this thread in a *nice* way, not saying "hey
man, go use something else" or "hey man, you suck" from each of the
"parties" (not that someone said something as rude as that).
My $0 (<- result if ${2/100} - sorry for that :)
Peter
> -----Original Message-----
> From: Daniel Dekany [mailto:ddekany@freemail.hu]
> Sent: Thursday, October 17, 2002 5:23 AM
> To: Velocity Users List
> Subject: Re: comparing monetary value
>
>
> Thursday, October 17, 2002, 2:22:14 AM, Geir Magnusson Jr. wrote:
>
> > On 10/16/02 3:19 PM, "Tim Colson" <tc...@cisco.com> wrote:
> >> Note: seems fair to disclose that Jonathan, to paraphrase the
> >> FreeMarker website, "rewrote the core of FreeMarker".
> Also, I noticed
> >> that Daniel is heavily active on the FM-DEV list. It
> puzzles me, but
> >> I will not speculate on why these gents are so worked up
> about having
> >> this feature in Velocity, since by Jonathan's own explanation, it
> >> already exists in the Freemarker template engine which both chaps
> >> seem to prefer.
> >>
> >
> > Yes, I too wonder why Jonathan and Daniel are so worked up
> about this.
>
> <OT>
> Could you please stop this "Jonathan and Daniel" thing... It
> such a waffle. If someone wonder, I tell you why I'm here:
> Simply, I heard that Jonathan is here, and I was Velocity
> list reader in the pre-FM 2.x times, and I was curious what
> will happen now. And I just can't stop myself to reply when I
> see something nonsense. It has nothing to do with the fact
> that I'm involved in FM. What's then? I don't get payment for
> FM users... </OT>
>
> So... returning to the essence...
>
> I don't understand why are you so reluctant about decimals.
> (Well, frankly, I have an idea, but I don't tell it again.)
> What are your counter arguments? (I ask you because you are
> the leader developer here, AFAIK.)
>
> To prevent needles communication, here are a few
> counter-arguments, and why are they invalid (IMO). I don't
> say here that you say these counter-arguments.
>
> 1.
> - Decimals inherently problematic because of the rounding
> complications (1.49999999999999 and such things).
> - Yes, but decimals are existing in the real-life. Is this a
> good logic when someone does not solve something because the
> solution is not trivial? Obviously it does not make sense.
> Also, exactly because it is not a trivial topic, it is better
> if Velocity solves this, than leave individuals to develop
> tools for it.
>
> 2.
> - It would complicate/distort the syntax.
> - I don't think so. The only point where it touches the
> syntax is that you can write constants like 1.5. But it is
> just a little extension of the syntax, right? Also, it is
> such an obvious thing.
>
> 3.
> - It would complicate/distort the semantic.
> - From the viewpoint of designer it would *simplify* the
> semantic. Everyday people find it natural that he can use
> decimals. Integers and decimals are not separated so strictly
> in the brain of non-programmer. They are just all numbers.
> What they don't find natural is that 90/100=0 (since it is
> nonsense), or that they can't compare two numbers, because
> one of them is not integer.
>
> 4.
> - Velocity should solve number formatting then.
> - It is cleanly an MVC view task, right? So it is the task of
> Velocity. Anyway, you must solve it, wether you like it or
> not, and now you are forced to solve it with custom tools.
> Not to mention that number formatting issues are existing
> even if you support integers only (e.g. someone may use
> grouping when display integers.) A standard tool is a
> possible solution.
>
> 5.
> - We just discuss that we will develop a standard tool...
> - That's OK for solving the formatting problem, but in fact
> it has nothing to do with the question (i.e. supporting
> decimals or not). Operators still will not work (90/100 = 0,
> relational operators don't work...). I know, you can use
> tools for do these things, but this in itself is not a
> counter-argument... maybe you can say that it makes decimals
> +0 in this field. However, I would disagree then: would not
> it be much better if 1/2 is simply 0.5?
>
> 6.
> - Designers needs only integers
> - I don't think so, but that's a somewhat subjective
> question. Also, I guess the number of requests means that it
> is not that uncommon thing that someone need decimals. But
> even if they need it 1 times per 1000 year (I doubt), in
> itself it is again a +0 argument.
>
>
> So the main point is that simply I don't see a reason
> *against* decimals (while I and many other uses see reasons
> *for* decimals). Why would be that harmful?
>
> So, what are your *counter-arguments* against decimals?
>
>
> --
> To unsubscribe, e-mail:
> <mailto:velocity-user-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: comparing monetary value
Posted by Peter Romianowski <me...@gmx.de>.
Just to end this thread, could one of the developers answer this
(very constructive) mail (I mean the one from Daniel) in *detail*.
I would love to use decimals too and I don't see why people deny that,
BUT nevertheless I love Velocity and I would *really*, I mean like
*desperately really* :), know why there are no decimals but only
integers supported. The number-formatting-feature is not the point,
that should be done by a tool.
Simply put, why is #if ($myIQ < 42.5) BAD? I know the answers are in
this and that mail, but please give me a simple single sentence starting
with "Velocity does not support decimals, because ...". I already
realized (partly the hard way :) that you will not implement decimals.
I will not switch over to another template engine, because Velocity's
simple design *rocks* (note: no contradiction here), although some
development could be done (decimals, macros, perhaps
whitespace-gobbling).
I would like to end this thread in a *nice* way, not saying "hey
man, go use something else" or "hey man, you suck" from each of the
"parties" (not that someone said something as rude as that).
My $0 (<- result if ${2/100} - sorry for that :)
Peter
> -----Original Message-----
> From: Daniel Dekany [mailto:ddekany@freemail.hu]
> Sent: Thursday, October 17, 2002 5:23 AM
> To: Velocity Users List
> Subject: Re: comparing monetary value
>
>
> Thursday, October 17, 2002, 2:22:14 AM, Geir Magnusson Jr. wrote:
>
> > On 10/16/02 3:19 PM, "Tim Colson" <tc...@cisco.com> wrote:
> >> Note: seems fair to disclose that Jonathan, to paraphrase the
> >> FreeMarker website, "rewrote the core of FreeMarker".
> Also, I noticed
> >> that Daniel is heavily active on the FM-DEV list. It
> puzzles me, but
> >> I will not speculate on why these gents are so worked up
> about having
> >> this feature in Velocity, since by Jonathan's own explanation, it
> >> already exists in the Freemarker template engine which both chaps
> >> seem to prefer.
> >>
> >
> > Yes, I too wonder why Jonathan and Daniel are so worked up
> about this.
>
> <OT>
> Could you please stop this "Jonathan and Daniel" thing... It
> such a waffle. If someone wonder, I tell you why I'm here:
> Simply, I heard that Jonathan is here, and I was Velocity
> list reader in the pre-FM 2.x times, and I was curious what
> will happen now. And I just can't stop myself to reply when I
> see something nonsense. It has nothing to do with the fact
> that I'm involved in FM. What's then? I don't get payment for
> FM users... </OT>
>
> So... returning to the essence...
>
> I don't understand why are you so reluctant about decimals.
> (Well, frankly, I have an idea, but I don't tell it again.)
> What are your counter arguments? (I ask you because you are
> the leader developer here, AFAIK.)
>
> To prevent needles communication, here are a few
> counter-arguments, and why are they invalid (IMO). I don't
> say here that you say these counter-arguments.
>
> 1.
> - Decimals inherently problematic because of the rounding
> complications (1.49999999999999 and such things).
> - Yes, but decimals are existing in the real-life. Is this a
> good logic when someone does not solve something because the
> solution is not trivial? Obviously it does not make sense.
> Also, exactly because it is not a trivial topic, it is better
> if Velocity solves this, than leave individuals to develop
> tools for it.
>
> 2.
> - It would complicate/distort the syntax.
> - I don't think so. The only point where it touches the
> syntax is that you can write constants like 1.5. But it is
> just a little extension of the syntax, right? Also, it is
> such an obvious thing.
>
> 3.
> - It would complicate/distort the semantic.
> - From the viewpoint of designer it would *simplify* the
> semantic. Everyday people find it natural that he can use
> decimals. Integers and decimals are not separated so strictly
> in the brain of non-programmer. They are just all numbers.
> What they don't find natural is that 90/100=0 (since it is
> nonsense), or that they can't compare two numbers, because
> one of them is not integer.
>
> 4.
> - Velocity should solve number formatting then.
> - It is cleanly an MVC view task, right? So it is the task of
> Velocity. Anyway, you must solve it, wether you like it or
> not, and now you are forced to solve it with custom tools.
> Not to mention that number formatting issues are existing
> even if you support integers only (e.g. someone may use
> grouping when display integers.) A standard tool is a
> possible solution.
>
> 5.
> - We just discuss that we will develop a standard tool...
> - That's OK for solving the formatting problem, but in fact
> it has nothing to do with the question (i.e. supporting
> decimals or not). Operators still will not work (90/100 = 0,
> relational operators don't work...). I know, you can use
> tools for do these things, but this in itself is not a
> counter-argument... maybe you can say that it makes decimals
> +0 in this field. However, I would disagree then: would not
> it be much better if 1/2 is simply 0.5?
>
> 6.
> - Designers needs only integers
> - I don't think so, but that's a somewhat subjective
> question. Also, I guess the number of requests means that it
> is not that uncommon thing that someone need decimals. But
> even if they need it 1 times per 1000 year (I doubt), in
> itself it is again a +0 argument.
>
>
> So the main point is that simply I don't see a reason
> *against* decimals (while I and many other uses see reasons
> *for* decimals). Why would be that harmful?
>
> So, what are your *counter-arguments* against decimals?
>
>
> --
> To unsubscribe, e-mail:
> <mailto:velocity-user-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, October 17, 2002, 2:22:14 AM, Geir Magnusson Jr. wrote:
> On 10/16/02 3:19 PM, "Tim Colson" <tc...@cisco.com> wrote:
>> Note: seems fair to disclose that Jonathan, to paraphrase the FreeMarker
>> website, "rewrote the core of FreeMarker". Also, I noticed that Daniel
>> is heavily active on the FM-DEV list. It puzzles me, but I will not
>> speculate on why these gents are so worked up about having this feature
>> in Velocity, since by Jonathan's own explanation, it already exists in
>> the Freemarker template engine which both chaps seem to prefer.
>>
>
> Yes, I too wonder why Jonathan and Daniel are so worked up about this.
<OT>
Could you please stop this "Jonathan and Daniel" thing... It such a
waffle. If someone wonder, I tell you why I'm here: Simply, I heard
that Jonathan is here, and I was Velocity list reader in the pre-FM
2.x times, and I was curious what will happen now. And I just can't
stop myself to reply when I see something nonsense. It has nothing to
do with the fact that I'm involved in FM. What's then? I don't get
payment for FM users...
</OT>
So... returning to the essence...
I don't understand why are you so reluctant about decimals. (Well,
frankly, I have an idea, but I don't tell it again.) What are your
counter arguments? (I ask you because you are the leader developer
here, AFAIK.)
To prevent needles communication, here are a few counter-arguments,
and why are they invalid (IMO). I don't say here that you say these
counter-arguments.
1.
- Decimals inherently problematic because of the rounding
complications (1.49999999999999 and such things).
- Yes, but decimals are existing in the real-life. Is this a good
logic when someone does not solve something because the solution is
not trivial? Obviously it does not make sense. Also, exactly because
it is not a trivial topic, it is better if Velocity solves this, than
leave individuals to develop tools for it.
2.
- It would complicate/distort the syntax.
- I don't think so. The only point where it touches the syntax is that
you can write constants like 1.5. But it is just a little extension of
the syntax, right? Also, it is such an obvious thing.
3.
- It would complicate/distort the semantic.
- From the viewpoint of designer it would *simplify* the semantic.
Everyday people find it natural that he can use decimals. Integers and
decimals are not separated so strictly in the brain of non-programmer.
They are just all numbers. What they don't find natural is that
90/100=0 (since it is nonsense), or that they can't compare two
numbers, because one of them is not integer.
4.
- Velocity should solve number formatting then.
- It is cleanly an MVC view task, right? So it is the task of
Velocity. Anyway, you must solve it, wether you like it or not, and
now you are forced to solve it with custom tools. Not to mention that
number formatting issues are existing even if you support integers
only (e.g. someone may use grouping when display integers.) A standard
tool is a possible solution.
5.
- We just discuss that we will develop a standard tool...
- That's OK for solving the formatting problem, but in fact it has
nothing to do with the question (i.e. supporting decimals or not).
Operators still will not work (90/100 = 0, relational operators don't
work...). I know, you can use tools for do these things, but this in
itself is not a counter-argument... maybe you can say that it makes
decimals +0 in this field. However, I would disagree then: would not
it be much better if 1/2 is simply 0.5?
6.
- Designers needs only integers
- I don't think so, but that's a somewhat subjective question. Also, I
guess the number of requests means that it is not that uncommon thing
that someone need decimals. But even if they need it 1 times per 1000
year (I doubt), in itself it is again a +0 argument.
So the main point is that simply I don't see a reason *against*
decimals (while I and many other uses see reasons *for* decimals). Why
would be that harmful?
So, what are your *counter-arguments* against decimals?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 10/16/02 3:19 PM, "Tim Colson" <tc...@cisco.com> wrote:
> Integer comparisons. Hah! ;-)
>
> So, by my count, the current talley of folks who want Velocity to handle
> non-integer arithmetic operations out of the box:
> +1 Jonathan
> +1 Daniel
> +1 Christoph
> -1 Tim
>
> Note: seems fair to disclose that Jonathan, to paraphrase the FreeMarker
> website, "rewrote the core of FreeMarker". Also, I noticed that Daniel
> is heavily active on the FM-DEV list. It puzzles me, but I will not
> speculate on why these gents are so worked up about having this feature
> in Velocity, since by Jonathan's own explanation, it already exists in
> the Freemarker template engine which both chaps seem to prefer.
>
Yes, I too wonder why Jonathan and Daniel are so worked up about this.
Maybe it's a feature they would need to switch from Freemarker to Velocity?
--
Geir Magnusson Jr.
geirm@adeptra.com +1-203-355-2219 (w)
Adeptra Inc. +1-203-247-1713 (m)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: floating point (was monetary value)
Posted by Aaron Held <aa...@MetroNY.com>.
Will Glass-Husain wrote:
> Personally, as an enthusiastic Velocity user, I like the sparse design, but
> still have a strong need for FP comparison. (to sum up-- it's confusing to
> the template designers to allow integers but not fp numbers. Frankly, they
> may not even understand the difference).
I have been using Cheetah Templates
(http://cheetahtemplate.org/index.html) a Python version of Velocity and
recently began using velocity.
In Cheetah any IF statement drops to a python expression, so my template
maintainers can compare any two objects. IMHO any object that the
template exposes should be comparable in an IF, because template authors
will try.
Thanks,
-Aaron Held
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: floating point (was monetary value)
Posted by Will Glass-Husain <wg...@forio.com>.
Hi,
I don't really feel a need to participate (again) in this debate, but did
want to note that your vote is wildly unrepresentative, as probably several
dozen people have weighed in with opinions in the past.
The issue has been discussed in detail in two major (50+ messages each)
threads in the 12 months I've been on this list. It more or less comes down
to a set of people saying "good design means there is no need for floating
point numbers in the template", and other people saying "but my project
could really benefit from this".
Personally, as an enthusiastic Velocity user, I like the sparse design, but
still have a strong need for FP comparison. (to sum up-- it's confusing to
the template designers to allow integers but not fp numbers. Frankly, they
may not even understand the difference).
And no, Jonathan, I don't need another plug for FreeMarker, thanks.
Best,
WILL
Tim Colson:
So, by my count, the current talley of folks who want Velocity to handle
non-integer arithmetic operations out of the box:
+1 Jonathan
+1 Daniel
+1 Christoph
-1 Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: comparing monetary value
Posted by Tim Colson <tc...@cisco.com>.
Hey gang -
Jonathan accused:
> You do seem to be deliberately missing the point.
At least I'm not deliberately beating a dead horse. <grin>
Anyway, I'll skip the baiting comments and focus on these two:
Jonathon posed:
> Velocity simply does not provide a solution for the localized
> (or even non-localized) display of decimal numbers.
> Whether it should do so is open to debate,
> but it mostly clearly does not address the issue.
Ok - I'll agree to both of those, keeping in mind that while Velocity
does not provide this OOTB (Out of the Box), it can indeed be
accomplished by writing a simple drop-in tool.
Personally, I'm happy with current functionality because I mostly push
all comparisons into the controller. Heck, I currently think any
comparisons except for "truth" is a slippery slope. Go ahead and call me
a Luddite, but I prefer simple, and I might even propose the removal of
Integer comparisons. Hah! ;-)
So, by my count, the current talley of folks who want Velocity to handle
non-integer arithmetic operations out of the box:
+1 Jonathan
+1 Daniel
+1 Christoph
-1 Tim
Note: seems fair to disclose that Jonathan, to paraphrase the FreeMarker
website, "rewrote the core of FreeMarker". Also, I noticed that Daniel
is heavily active on the FM-DEV list. It puzzles me, but I will not
speculate on why these gents are so worked up about having this feature
in Velocity, since by Jonathan's own explanation, it already exists in
the Freemarker template engine which both chaps seem to prefer.
Anyway - that's my vote for what it's worth (considerably less than
$0.0002 cents in USD or Lira).
Cheers,
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <re...@wanadoo.es>.
On Wednesday 16 October 2002 01:51 am, Tim Colson wrote:
> Daniel
>
> > Well, this is a MVC View tool, right? The formatting is the task of
> > the view component (Velocity). So it should give a solution to do the
> > formatting. Something like ${foo*1.234|0.00}.
>
> Obviously, opinions will differ. For me, Velocity suits just fine
> because I choose to do this: $preferredLocalPrice instead of
> ${foo*1.234|0.00}
You do seem to be deliberately missing the point. You can choose
$preferredLocalPrice because you're a java programmer and you can put hte
necessary logic in the back end. Someone working on the template level cannot
do that. OTOH, they can write foo*1.234.
> But to the point that [velocity] should give a solution. It does. Write
> a tool. Drop it into the context. Done.
Well.... excuse me.... To say that Velocity provides a solution, which is to
write your own tool, just seems like double-talk to me. It is almost akin to
proposing that the solution to the lack of floating point numbers is in fact
not to use floating point numbers.
The fact remains that Velocity (and this may be by neglect, or by conscious
choice) simply does not address the issue. To say that somebody has the means
to provide a custom solution is not the same as saying that Velocity provides
a solution. It simply does not. Velocity simply does not provide a solution
for the localized (or even non-localized) display of decimal numbers. Whether
it should do so is open to debate, but it mostly clearly does not address the
issue.
>
> > There is one BIG mistake in this reasoning.
>
> It's not a mistake, it's my opinion, to which I feel entitled to have.
Tim, it follows logically that what you are expressing is your opinion. (I
take that as a given.) It also follows logically that you are entitled to
have that opinion. (I don't question that either.) But it does not follow
from there that the opinion in question is not mistaken. Or based on mistaken
reasoning... (though in that case, you'd still be entitled to hold said
opinion... :-)
<sigh>
> And I choose to use Velocity as it stands because it solves my needs. If
> it isn't a good fit for your problem, may I suggest trying or writing
> something else.
Well, I think that is quite a valid point. If you want features that Velocity
does not have, you should try something else that has those features.
Particularly given the culture here, it does not seem that waiting for the
Velocity developers to implement the desired feature is likely to be
fruitful.
>
> > Basically you said here
> > that if the designer uses decimals, then he probably does the task of
> > the programmers, also probably he will do something silly.
> >... It is IMO not a valid argument that Velocity
> > doesn't support decimals because it may allow designer to do something
> > that is not his/her task. With this logic, Velocity should not support
> > #if, because the designer perhaps will do something silly with that...
>
> I suggested no such thing(s), please don't put words into my mouth.
>
> What I suggested was an alternative solution that can be carried out
> with the released version of Velocity. I did not speculate why floats
> are not handled.
>
> Actually, in the past, I have asked why all number types aren't treated
> the same. The reality is that for whatever reason, Velocity doesn't work
> that way. So I could either stop whining and work with what's there,
> choose a different template engine, or write my own. I decided it really
> wasn't a big deal, and in fact, now I don't even use the integer
> comparison in my templates and I'm happy.
Well, it's good that you're happy. Personally, I would find limiting myself to
such a small feature set to be too restrictive. But it's up to everybody to
assess their options and make their own decisions. (To recap, it's their
decision, they're entitled to make it, and it may or may not be mistaken....)
That much seems clear.
Regards,
Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: comparing monetary value
Posted by Tim Colson <tc...@cisco.com>.
Daniel
> Well, this is a MVC View tool, right? The formatting is the task of
> the view component (Velocity). So it should give a solution to do the
> formatting. Something like ${foo*1.234|0.00}.
Obviously, opinions will differ. For me, Velocity suits just fine
because I choose to do this: $preferredLocalPrice instead of
${foo*1.234|0.00}
But to the point that [velocity] should give a solution. It does. Write
a tool. Drop it into the context. Done.
> There is one BIG mistake in this reasoning.
It's not a mistake, it's my opinion, to which I feel entitled to have.
And I choose to use Velocity as it stands because it solves my needs. If
it isn't a good fit for your problem, may I suggest trying or writing
something else.
> Basically you said here
> that if the designer uses decimals, then he probably does the task of
> the programmers, also probably he will do something silly.
>... It is IMO not a valid argument that Velocity
> doesn't support decimals because it may allow designer to do something
> that is not his/her task. With this logic, Velocity should not support
> #if, because the designer perhaps will do something silly with that...
I suggested no such thing(s), please don't put words into my mouth.
What I suggested was an alternative solution that can be carried out
with the released version of Velocity. I did not speculate why floats
are not handled.
Actually, in the past, I have asked why all number types aren't treated
the same. The reality is that for whatever reason, Velocity doesn't work
that way. So I could either stop whining and work with what's there,
choose a different template engine, or write my own. I decided it really
wasn't a big deal, and in fact, now I don't even use the integer
comparison in my templates and I'm happy.
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Daniel Dekany <dd...@freemail.hu>.
Tuesday, October 15, 2002, 8:38:03 PM, Tim Colson wrote:
> Jonathan wrote:
>> So, instead of simply having:
>> The price is: $price euros.
>> The price is: $price euros. (${price*6.556 FFR)
[snip]
> So, I will explicitly say that I personally would indeed expect a
> non-technical designer to ask the Developer for this feature, rather
> than hack it in directly because the template system made it possible.
>
> "some reason": I can propose several reasons why this situation could be
> bad in my opinion:
>
> 1) the conversion rate changes tomorrow to 5.998
Well, Jonathan's example was rather unlucky, but probably you see the
meat...
> 2) each user has customized preferences for selecting her preferred
> alternative currency (FFR, DM, USD, etc.)
(See above... this was not the point here.)
> 3) the result of $price * $conversionRate will still need to have the
> correct rounding and formatting for the resulting currency. (Ex. DM 6,03
> or $6.03 USD - not $6.0029999987 DM)
Well, this is a MVC View tool, right? The formatting is the task of
the view component (Velocity). So it should give a solution to do the
formatting. Something like ${foo*1.234|0.00}.
> Summary: my solution, using Velocity, would be to do this work in the
> controller and give the template designer simply $price and
> $preferredLocalPrice.
[snip]
There is one BIG mistake in this reasoning. Basically you said here
that if the designer uses decimals, then he probably does the task of
the programmers, also probably he will do something silly. But in
fact, the designer can do stupid things with integers as well... and
with anything else. It is IMO not a valid argument that Velocity
doesn't support decimals because it may allow designer to do something
that is not his/her task. With this logic, Velocity should not support
#if, because the designer perhaps will do something silly with that...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: comparing monetary value
Posted by Tim Colson <tc...@cisco.com>.
Jonathan wrote:
> So, instead of simply having:
> The price is: $price euros.
> The price is: $price euros. (${price*6.556 FFR)
> What you seem to be implying is
> that the non-technical people who want to introduce this
> change should have to talk to the programmers so that they expose the
constant
> in the template.
> For some reason, it is "bad" (TM) for them to write 6.556
> literally in the template.
I do not assume 'implied things' since that puts words in peoples
mouths.
So, I will explicitly say that I personally would indeed expect a
non-technical designer to ask the Developer for this feature, rather
than hack it in directly because the template system made it possible.
"some reason": I can propose several reasons why this situation could be
bad in my opinion:
1) the conversion rate changes tomorrow to 5.998
2) each user has customized preferences for selecting her preferred
alternative currency (FFR, DM, USD, etc.)
3) the result of $price * $conversionRate will still need to have the
correct rounding and formatting for the resulting currency. (Ex. DM 6,03
or $6.03 USD - not $6.0029999987 DM)
Summary: my solution, using Velocity, would be to do this work in the
controller and give the template designer simply $price and
$preferredLocalPrice.
Cheers,
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Jonathan Revusky <re...@wanadoo.es>.
On Tuesday 15 October 2002 04:55 pm, Geir Magnusson Jr wrote:
> On 10/15/02 2:06 AM, "STham@thoughtworks.COM" <ST...@thoughtworks.COM>
>
> wrote:
> > Hi,
> >
> > I believed at the moment, all numbers are treated as Integer. Anyone
> > came across this problem of manipulating with money value before?
> >
> > Example :
> >
> > Give a certain amount has to be less than a given value.
> >
> > if ($someMoneyValue < 0.01) ???
> >
> > How do people normally handle money in velocity?? Thanks.
>
> Just to give some background (and this is another subject if much heated
> discussion)...
>
> The idea behind not having floating point number support is that it allows
> one to wander from the notion that Velocity templating is used for the view
> layer, and begin to do things that other parts of you program should be
> doing.
>
> So when you put something like 0.01 in a template, that should actually be
> data from your data model, like $maxAmount or the like.
>
> Now, currently velocity won't allow that - you can't play by the rule I
> just suggested and do somethinng like
>
> #if ($someMoneyValye < $maxAmount)
> ....
>
> Because < operates only on integers. This is another exhibition of the
> initial idea that VTL features were for the designers (we had a huge fight
> about % IIRC, to give you an idea how strong some of the feelings were
> about this.)
Well, of course a templating language should be oriented towards the designers
and other non-technical people. However, the idea that you have to be a
programmer to need decimal numbers strikes me as rather far-fetched frankly.
I mean, presumably, designers are citizens who fill out their income tax every
year, and in so doing, they use decimal numbers and four-function calculator
arithmetic.
>
> So to solve the problem, you would add a tool, some generic number
> comparison tool to do
>
> #if ($myTool.lessThan($someValye, $maxAmount))
> ...
>
> That is the solution we all do now.
Well, I suppose that's true if you don't include the people who have switched
to FreeMarker (there are at least a couple I know of). Those people write:
<if someValue < maxAmount>
....
</if>
;-)
>
> My personal position on this has moved - I have been playing with allowing
> floating point *comparison* w/o allowing floating point literals in other
> Velocity-like systems I work on, keeping the idea that any such literal has
> to be data in the model (as I can't think of any reason why a designer
> would need it for calculating display-related values, like rows or
> columns...
Well, I don't think you're trying very hard, frankly. Surely it's easy enough
to come up with examples where a non-programmer would want to do some
non-integer arithmetic in a template. For example, in Europe recently, there
was this big move to the euro, the unified currency. As it happens, most
people in the euro zone do not have a good intuitive feel for the euro and
still reckon things in the old currency -- francs, deutsche marks, etcetera.
Imagine a simple app, a catalogue, where you display the price of things. The
catalogue is in euros, of course. A non-technical manager points out that it
would be better to show the amount in the superseded local currency in
parentheses.
So, instead of simply having:
The price is: $price euros.
they want:
The price is: $price euros. (${price*6.556 FFR)
let's say for French francs in this example. What you seem to be implying is
that the non-technical people who want to introduce this change should have
to talk to the programmers so that they expose the constant in the template.
For some reason, it is "bad" (TM) for them to write 6.556 literally in the
template.
(Of course, the same argument could be made for conversions between celsius
and farenheit, kilometres and miles, and so on... Basically, these units of
measure are just alternative ways of presenting the same canonical
information and it's not clear why somebody working on the view level should
not have the full discretion to do this stuff without the intervention of
programmers.)
But what I don't understand about all of this is, what is the justification
for letting people write a literal string or a literal integer but not a
literal decimal number.
I mean, why would you support decimal numbers (in some hypothetical future
version) and let people write:
#set $x=1
and NOT let them write:
#set $x=1.1
It just seems terribly non-orthogonal. Is there really any justification
(either theoretical or pragmatic) for such a non-orthogonality?
I actually recall posing this question before and never receiving a response.
> I guess in real graphics design you do fractional units of
> measure, but I suppose you wouldn't use Velocity for that anyway...). The
> other Vel-like things I work on are not templating systems, but scripting
> environments where floating point comparisons are fully required, so maybe
> my thinking is getting 'polluted' by working in Vel-like scripting tools...
Well, my take on this is that your thinking is just getting "polluted" by
actually having real-world problems to solve. You finally had to yield to the
evidence and accept that decimal numbers are... err.... kinda useful
sometimes... ;-)
Best Regards,
Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Daniel Dekany <dd...@freemail.hu>.
Tuesday, October 15, 2002, 5:41:25 PM, Geir Magnusson Jr wrote:
[snip]
> On 10/15/02 11:20 AM, "Tim Colson" <tc...@cisco.com> wrote:
>> My alternative: iterate over the rows in the controller, do the logical
>> comparison and set a meta-data boolean into each row: $IS_INSIGNIFICANT.
>>
>> The Designer then only has to use: #if ($IS_INSIGNIFICANT)
>> background="grey" #end
>>
>> I find that: #if ($CONDITION) #end is far easier for a Designer to
>> write, and constitutes about 90% of their conditions anyway. :-)
>>
>> Summary: We get simpler templates, pure from any possible biz-logic
>> contamination, but with a bit more work from Developers.
>
> Yes - that is the pure approach, and I think the best one if you are willing
> to take the time to do it right (while the rest of us do it over...). Glad
> to know that it works - it was always a theory to me :)
I have the feeling that the real reason behind not supporting decimals
is that the developers felt that it would be too hard or too many time
to add that... you know, that big always-buggy Java source code, it is
better if you don't touch that. So they have figured out a lot of
"scientific" objection instead. And now, even if some of the smart
users send a patch, they will not accept that, because they have to
adhere to this spurious academic viewpoint: "Decimals in templates are
bad!". They have said it so much, that probably now they really
believe it; ditto for many list readers who has heard this for too
many times. Also, since Velocity is inside apache.org, users (list
readers) are inclined to give more credit to Velocity and Velocity
developers. So it is hard to archive any improvements here.
And the above also stands for other issues, like the good-old
whitespace gobbling. Just my opinion...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Geir Magnusson Jr <ge...@optonline.net>.
On 10/15/02 11:20 AM, "Tim Colson" <tc...@cisco.com> wrote:
>
>>> Example :
>>> Give a certain amount has to be less than a given value.
>>> if ($someMoneyValue < 0.01) ???
>>> How do people normally handle money in velocity?? Thanks.
>
> Geir replied :
>> So to solve the problem, you would add a tool, some generic number
>> comparison tool to do
>> #if ($myTool.lessThan($someValye, $maxAmount))
>> That is the solution we all do now.
>
> Well...not all of us. ;-)
Ya, ya. I realized I was being a bit presumptuous, but I just did a redeye
into London (anyone in London?), so I'm lazier than usual...
>
> Rather than provide a context tool, I 'pull this up' into the
> controller.
>
> Before folks say, "But [insert favorite comparison here] is ONLY a
> Design decision," I'll caveat that I feel that case is rare if not
> impossible to find.
>
> My view on this comes from working with HTML::Template in Perl. There
> are -no- comparisons, only tests for "truth".
> http://www.perldoc.com/cpan/HTML/Template.html
And beauty?
> I personally think that this the purest way to go for a template engine,
> and that having any comparison in the template is probably not a good
> thing. Most developers don't like the idea at first because, well, quite
> frankly, we're lazy and this solution requires more work from us.
>
> Consider the example above, let us assume the data is destined for a
> table. The Designer perhaps wants to set the background to grey for rows
> where $someMoneyValue < 0.01.
>
> My alternative: iterate over the rows in the controller, do the logical
> comparison and set a meta-data boolean into each row: $IS_INSIGNIFICANT.
>
> The Designer then only has to use: #if ($IS_INSIGNIFICANT)
> background="grey" #end
>
> I find that: #if ($CONDITION) #end is far easier for a Designer to
> write, and constitutes about 90% of their conditions anyway. :-)
>
> Summary: We get simpler templates, pure from any possible biz-logic
> contamination, but with a bit more work from Developers.
Yes - that is the pure approach, and I think the best one if you are willing
to take the time to do it right (while the rest of us do it over...). Glad
to know that it works - it was always a theory to me :)
--
Geir Magnusson Jr.
geirm@adeptra.com +1-203-355-2219 (w)
Adeptra Inc. +1-203-247-1713 (m)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: comparing monetary value
Posted by Tim Colson <tc...@cisco.com>.
> > Example :
> > Give a certain amount has to be less than a given value.
> > if ($someMoneyValue < 0.01) ???
> > How do people normally handle money in velocity?? Thanks.
Geir replied :
> So to solve the problem, you would add a tool, some generic number
> comparison tool to do
> #if ($myTool.lessThan($someValye, $maxAmount))
> That is the solution we all do now.
Well...not all of us. ;-)
Rather than provide a context tool, I 'pull this up' into the
controller.
Before folks say, "But [insert favorite comparison here] is ONLY a
Design decision," I'll caveat that I feel that case is rare if not
impossible to find.
My view on this comes from working with HTML::Template in Perl. There
are -no- comparisons, only tests for "truth".
http://www.perldoc.com/cpan/HTML/Template.html
I personally think that this the purest way to go for a template engine,
and that having any comparison in the template is probably not a good
thing. Most developers don't like the idea at first because, well, quite
frankly, we're lazy and this solution requires more work from us.
Consider the example above, let us assume the data is destined for a
table. The Designer perhaps wants to set the background to grey for rows
where $someMoneyValue < 0.01.
My alternative: iterate over the rows in the controller, do the logical
comparison and set a meta-data boolean into each row: $IS_INSIGNIFICANT.
The Designer then only has to use: #if ($IS_INSIGNIFICANT)
background="grey" #end
I find that: #if ($CONDITION) #end is far easier for a Designer to
write, and constitutes about 90% of their conditions anyway. :-)
Summary: We get simpler templates, pure from any possible biz-logic
contamination, but with a bit more work from Developers.
Cheers,
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: comparing monetary value
Posted by Geir Magnusson Jr <ge...@optonline.net>.
On 10/15/02 2:06 AM, "STham@thoughtworks.COM" <ST...@thoughtworks.COM>
wrote:
>
> Hi,
>
> I believed at the moment, all numbers are treated as Integer. Anyone
> came across this problem of manipulating with money value before?
>
> Example :
>
> Give a certain amount has to be less than a given value.
>
> if ($someMoneyValue < 0.01) ???
>
> How do people normally handle money in velocity?? Thanks.
Just to give some background (and this is another subject if much heated
discussion)...
The idea behind not having floating point number support is that it allows
one to wander from the notion that Velocity templating is used for the view
layer, and begin to do things that other parts of you program should be
doing.
So when you put something like 0.01 in a template, that should actually be
data from your data model, like $maxAmount or the like.
Now, currently velocity won't allow that - you can't play by the rule I just
suggested and do somethinng like
#if ($someMoneyValye < $maxAmount)
....
Because < operates only on integers. This is another exhibition of the
initial idea that VTL features were for the designers (we had a huge fight
about % IIRC, to give you an idea how strong some of the feelings were about
this.)
So to solve the problem, you would add a tool, some generic number
comparison tool to do
#if ($myTool.lessThan($someValye, $maxAmount))
...
That is the solution we all do now.
My personal position on this has moved - I have been playing with allowing
floating point *comparison* w/o allowing floating point literals in other
Velocity-like systems I work on, keeping the idea that any such literal has
to be data in the model (as I can't think of any reason why a designer would
need it for calculating display-related values, like rows or columns... I
guess in real graphics design you do fractional units of measure, but I
suppose you wouldn't use Velocity for that anyway...). The other Vel-like
things I work on are not templating systems, but scripting environments
where floating point comparisons are fully required, so maybe my thinking is
getting 'polluted' by working in Vel-like scripting tools...
--
Geir Magnusson Jr.
geirm@adeptra.com +1-203-355-2219 (w)
Adeptra Inc. +1-203-247-1713 (m)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>