You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by lloyd <su...@twilight-systems.com> on 2002/05/05 20:44:31 UTC

DECIMAL POINTS (once more with feeling)

while i have no opinion re: Revusky on issues of list etiquette and
civility, i have been silently cheering him on when it comes to the
floating point issue.  i think the designer should at least be able to
*identify* a number with decimal points in VTL.  

an example from one of my own projects: a designer simply wanted to
suppress the display of float values if they were zero (like a
spreadsheet when you have "hide zeros" turned on).  they were cluttering
up his tables with useless noise. he could not understand why something
as simple as comparing a value for equality to zero was beyond
Velocity's capabilities.  explaining the separation of logic and content
did *no good* - his eyes glazed over, and i could see the question
forming in his mind: "are you telling me i have to come to *you* to
program a special object every time i want to know if a f*cken number is
zero or not?" 

and, actually, i'm thinking the exact same thing:  "you mean i have to
program a special object every time he wants to know if a f*cken number
is zero or not?"  

sometimes the designer wants to spiff up a page in ways that are
entirely irrelevant to the logic of an application, but that require
knowledge of the value of a number that happens to have a decimal point
in it.  frankly, i don't care if the designer wants to suppress zeros,
or highlight negative numbers in red, or other exceedingly minor
presentation-level decisions that i shouldn't *have* to care about. i
don't think my account balance object should have a .isZero() method, or
a .getHighlightColor() method.  nor do i want to create a separate
shadow object for every single object with a decimaled number.  nor do i
want to create VelocityUtis.isZero() or .compareFloats() method - this
is little different from having the ability to examine numbers directly.

i think the original premise of templating vs. JSP - separating the
logic out of the presentation - is of course entirely valid, and anyone
who has used the technology for awhile (or simply read YMTD) would
agree.  but lack of floats in velocity is having the opposite effect -
it's dragging presentation-level responsibilities into my lap. 

i know this floating point thing has acquired a cult-like aura around it
and that the parties involved are deeply entrenched.  so, i'll get to
the point - i have two questions in mind: 

1)  is it a lot of work to add at least *comparison" operators for
numbers with decimal points?  in other words, the ability to inspect
them, but not do anything (like math) with them? 

2)  would it be more palatable to those who dislike decimal points if
this capability were added, but with a velocity setting that allows you
to toggle it on/off? 

3)  if someone were to develop this capability independently, would it
get checked into the code base? 

4)  if not, would the velocity developers play nice with a module fork
or "floats patch"? 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DECIMAL POINTS (once more with feeling)

Posted by Nathan Bubna <na...@esha.com>.
lloyd said:
> and, actually, i'm thinking the exact same thing:  "you mean i have to
> program a special object every time he wants to know if a f*cken number
> is zero or not?"  

#set( $foo = $someFloatingPointNumberIFoundInTheContext )
#if( $foo.intValue() == 0 )
    look ma! no tool was used!
#end

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DECIMAL POINTS (once more with feeling)

Posted by Jonathan Revusky <jr...@terra.es>.
Geir Magnusson Jr. wrote:
> On 5/5/02 2:50 PM, "Will Glass-Husain" <wg...@forio.com> wrote:
> 
> 
>>Well said.  we love Velocity, but this is the number 1 limitation for us.  to
>>the template designer, there is no difference between an integer and floating
>>point-- why limit one but not the other?  It'd be great if someone were to
>>step 
>>up to the plate with a patch that would allow this.
> 
> 
> There are two aspects to the problem.  I sit on the fence with this issue,
> leaning towards the pro-float side.
> 
> I am on the pro-float side in that I think that the comparisons should
> support floating point arithmetic :
> 
>   #if( $total < $limit )
> 
> And when I get the parser stuff finished, I am happy put that in so we can
> play with it.  I have done it in other projects, and there are few problems.
> (The problems come in with people understanding coercion et al...)
> 
> What I am not convinced about is
> 
>   #if($total < 100.25)
> 
> with the reason being the usual that it's bad practice to embed a constant
> like that , and not sure there is a need in a system where the data is
> supposed to come from elsewhere.

Hey, I don't quite get it. If you can embed a string constant as in

if ($word == "foo")

why on earth should you *not* be able to embed a numerical constant?

if ($number == 100.25)

> 
> If you remember way back, we really gave a hard stare at numbers in general.
> Some believed that any arithmetic should be kept out of Velocity, but it's
> clear that simple integer arithmetic is critical for designers to do layout.
> 
> That's the crux of the VTL literal issue : do designers need to have
> floating point numbers embedded in templates?  I don't think there are any
> reasonable arguments one could make, as I as well as other believe that
> 
>   #if($total < $max )
> 
> Is much better practice than
> 
>   #if($total < 100.00)

Well, it seems terribly non-orthogonal to me. If you allow a string 
literal constant and not a numerical literal.

Well, also rather misguided.... yaknow, this idea that you're going to 
force people into "good" practices to this extent. It strikes me as 
something that should be in a HOWTO entitled "How to be a PITA" ;-)

> 
> Because when the application's notion of 'max' changes, off you go finding
> all the uses in the template. 

Well, the same thing applies to string literals. <sigh>

Tell me something. Is this the first time you've seriously thought about 
this stuff?

If so, I guess I've done all you guys a favor.

(Sheesh, personally, I would have preferred Velocity to continue without 
floating point....:-))


> It's the same reason why you use static
> 'constants' in Java and #defines in C (and enums in C++, I guess).

Neither language forces you into the "good" practice. That would be 
annoying.

> 
> So that's the issue : if you believe that this is a templating system rather
> than a scripting environment, then is there a reason to represent floating
> point numbers?

Hey, could you tell me something? What is the difference between a 
templating system and a scripting environment?

(Sheesh, I just gotta enlarge my vocabulary. The problem is that all the 
spam I receive only offers to enlarge my penis. <sigh>)

Ciao,

Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting



> 
> geir
> 
> 
>>best, wgh
>>
>>Quoting lloyd <su...@twilight-systems.com>:
>>
>>
>>>while i have no opinion re: Revusky on issues of list etiquette and
>>>civility, i have been silently cheering him on when it comes to the
>>>floating point issue.  i think the designer should at least be able to
>>>*identify* a number with decimal points in VTL.
>>>
>>
>>------------------------------------
>>Will Glass-Husain  <wg...@forio.com>
>>Forio Business Simulations
>>office: (415) 440-7500
>>mobile: (415) 235-4293
>>
>>--
>>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: DECIMAL POINTS (once more with feeling)

Posted by "Charles N. Harvey III" <ch...@alloy.com>.
I am inclined to like such a syntax for float objects:

Hey, I don't quite get it. If you can embed a string constant as in

#if ($word == "foo")

#if ($number == 100.25)

I have worked in a bunch of different scripting languages and compiled
languages (although much more in the scripting kind) and it has always
been clear to me and to any of the other developers in my office that
"100.25" is a string and 100.25 is a number.

Now, so far I haven't had a use for floats.  But it might happen someday...
And I think if it did that the syntax above would make the most sense
to me.

Although I am easily persuaded and the arguments that Geir has made
previously make it a tough call.

Just my two cents.

Charlie

> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> Sent: Sunday, May 05, 2002 6:39 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: DECIMAL POINTS (once more with feeling)
>
>
> On 5/5/02 6:27 PM, "Thomas Åhlén" <th...@obidobi.net> wrote:
>
> >> I am on the pro-float side in that I think that the comparisons should
> >> support floating point arithmetic :
> >>
> >>   #if( $total < $limit )
> >>
> >
> > Even if floating point arithmetric are going to be supported or
> not I think
> > that Long values should be supported.
> >
> > #if( $id < 10 )
> >
> > gives an error if $id is of type Long.
> >
> > Thomas Åhlén
> >
>
> Agreed.  Putting any args aside about float, agreed.
>
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> 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: DECIMAL POINTS (once more with feeling)

Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/5/02 6:27 PM, "Thomas Åhlén" <th...@obidobi.net> wrote:

>> I am on the pro-float side in that I think that the comparisons should
>> support floating point arithmetic :
>> 
>>   #if( $total < $limit )
>> 
> 
> Even if floating point arithmetric are going to be supported or not I think
> that Long values should be supported.
> 
> #if( $id < 10 )
> 
> gives an error if $id is of type Long.
> 
> Thomas Åhlén
> 

Agreed.  Putting any args aside about float, agreed.

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DECIMAL POINTS (once more with feeling)

Posted by Thomas Åhlén <th...@obidobi.net>.
> I am on the pro-float side in that I think that the comparisons should
> support floating point arithmetic :
>
>   #if( $total < $limit )
>

Even if floating point arithmetric are going to be supported or not I think
that Long values should be supported.

#if( $id < 10 )

gives an error if $id is of type Long.

Thomas Åhlén


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DECIMAL POINTS (once more with feeling)

Posted by Will Glass-Husain <wg...@forio.com>.
Hi Geir,

Glad to hear it.  Implementing the first (comparing floating point references) 
will be a big help.  Implementing the second (explicit use of floating point 
numbers in the VTL) will make the language a bit more consistent from a user 
perspective (since you can already use integers).  For example, it will let us 
do this (which we currently struggle with)

<select name="Choose a new price for your product offering" >
  <option value="1.50" #if($LastValue=1.50)selected#end >
    Low Price
  </option>
  <option value="5.00" #if($LastValue=5.00)selected#end >
    Medium Price
  </option>
  <option value="10.00" #if($LastValue=10.00)selected#end >
    High Price
  </option>

I recognize from a classical standpoint it might be better to put the specific 
numbers in the model.  But this is easy for the developer to do, and hard for 
me to explain why it doesn't work.

Still, the first of your options will make a big difference for us.  Let me 
know If I can help with use cases, etc.

best, WGH.

> I am on the pro-float side in that I think that the comparisons should
> support floating point arithmetic :
> 
>   #if( $total < $limit )
> 
> What I am not convinced about is
> 
>   #if($total < 100.25)
> 
> geir


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DECIMAL POINTS (once more with feeling)

Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/5/02 4:31 PM, "Terry Steichen" <te...@net-frame.com> wrote:

> Geir,
> 
> Sounds reasonable.  Maybe it would help if you got more specific on what you
> consider to be the main points of the distinction you make between a
> template versus a script (versus core, Java-level action module code, if
> that's not considered a script).  I think we all realize that any
> application needs both (or all three, depending on where Java fits in).

To me, the difference between templating and scripting is fundamentally the
difference between 'uses' and 'is used by'.

With templating, the designer creates an entity (the template) that will be
used by 'something else' to render or output data in a format or pattern
dictated by the template.   Also, I think personally that the templating
system should be as simple as possible, not because designers are 'stupid'
or anything, but because you are forcing them to work in a system for which
skills therein are of secondary importance to the skills of the primary
activity, the organization and presentation of information.  Of course,
programmers also use the templating system, and there lies the rub, I
believe.

I see scripting as more of a general purpose 'control' system where the use
is completely general - you can use it to output and format data, you can
use it to control other subsystems, etc.  The feature set therefore has to
be richer, as the intended usage is general.

I am not sure if that really captured the mental picture of how I see them
as different, but I hope it's a start.

geir

> 
> Regards,
> 
> Terry
> 
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@adeptra.com>
> To: <ve...@jakarta.apache.org>
> Sent: Sunday, May 05, 2002 3:59 PM
> Subject: Re: DECIMAL POINTS (once more with feeling)
> 
> 
>> On 5/5/02 2:50 PM, "Will Glass-Husain" <wg...@forio.com> wrote:
>> 
>>> 
>>> Well said.  we love Velocity, but this is the number 1 limitation for
> us.  to
>>> the template designer, there is no difference between an integer and
> floating
>>> point-- why limit one but not the other?  It'd be great if someone were
> to
>>> step
>>> up to the plate with a patch that would allow this.
>> 
>> There are two aspects to the problem.  I sit on the fence with this issue,
>> leaning towards the pro-float side.
>> 
>> I am on the pro-float side in that I think that the comparisons should
>> support floating point arithmetic :
>> 
>>   #if( $total < $limit )
>> 
>> And when I get the parser stuff finished, I am happy put that in so we can
>> play with it.  I have done it in other projects, and there are few
> problems.
>> (The problems come in with people understanding coercion et al...)
>> 
>> What I am not convinced about is
>> 
>>   #if($total < 100.25)
>> 
>> with the reason being the usual that it's bad practice to embed a constant
>> like that , and not sure there is a need in a system where the data is
>> supposed to come from elsewhere.
>> 
>> If you remember way back, we really gave a hard stare at numbers in
> general.
>> Some believed that any arithmetic should be kept out of Velocity, but it's
>> clear that simple integer arithmetic is critical for designers to do
> layout.
>> 
>> That's the crux of the VTL literal issue : do designers need to have
>> floating point numbers embedded in templates?  I don't think there are any
>> reasonable arguments one could make, as I as well as other believe that
>> 
>>   #if($total < $max )
>> 
>> Is much better practice than
>> 
>>   #if($total < 100.00)
>> 
>> Because when the application's notion of 'max' changes, off you go finding
>> all the uses in the template.  It's the same reason why you use static
>> 'constants' in Java and #defines in C (and enums in C++, I guess).
>> 
>> So that's the issue : if you believe that this is a templating system
> rather
>> than a scripting environment, then is there a reason to represent floating
>> point numbers?
>> 
>> geir
>> 
>>> 
>>> best, wgh
>>> 
>>> Quoting lloyd <su...@twilight-systems.com>:
>>> 
>>>> while i have no opinion re: Revusky on issues of list etiquette and
>>>> civility, i have been silently cheering him on when it comes to the
>>>> floating point issue.  i think the designer should at least be able to
>>>> *identify* a number with decimal points in VTL.
>>>> 
>>> 
>>> ------------------------------------
>>> Will Glass-Husain  <wg...@forio.com>
>>> Forio Business Simulations
>>> office: (415) 440-7500
>>> mobile: (415) 235-4293
>>> 
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>> 
>> 
>> --
>> Geir Magnusson Jr.
>> Research & Development, Adeptra Inc.
>> geirm@adeptra.com
>> +1-203-247-1713
>> 
>> 
>> 
>> --
>> 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>
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DECIMAL POINTS (once more with feeling)

Posted by Terry Steichen <te...@net-frame.com>.
Geir,

Sounds reasonable.  Maybe it would help if you got more specific on what you
consider to be the main points of the distinction you make between a
template versus a script (versus core, Java-level action module code, if
that's not considered a script).  I think we all realize that any
application needs both (or all three, depending on where Java fits in).

Regards,

Terry

----- Original Message -----
From: "Geir Magnusson Jr." <ge...@adeptra.com>
To: <ve...@jakarta.apache.org>
Sent: Sunday, May 05, 2002 3:59 PM
Subject: Re: DECIMAL POINTS (once more with feeling)


> On 5/5/02 2:50 PM, "Will Glass-Husain" <wg...@forio.com> wrote:
>
> >
> > Well said.  we love Velocity, but this is the number 1 limitation for
us.  to
> > the template designer, there is no difference between an integer and
floating
> > point-- why limit one but not the other?  It'd be great if someone were
to
> > step
> > up to the plate with a patch that would allow this.
>
> There are two aspects to the problem.  I sit on the fence with this issue,
> leaning towards the pro-float side.
>
> I am on the pro-float side in that I think that the comparisons should
> support floating point arithmetic :
>
>   #if( $total < $limit )
>
> And when I get the parser stuff finished, I am happy put that in so we can
> play with it.  I have done it in other projects, and there are few
problems.
> (The problems come in with people understanding coercion et al...)
>
> What I am not convinced about is
>
>   #if($total < 100.25)
>
> with the reason being the usual that it's bad practice to embed a constant
> like that , and not sure there is a need in a system where the data is
> supposed to come from elsewhere.
>
> If you remember way back, we really gave a hard stare at numbers in
general.
> Some believed that any arithmetic should be kept out of Velocity, but it's
> clear that simple integer arithmetic is critical for designers to do
layout.
>
> That's the crux of the VTL literal issue : do designers need to have
> floating point numbers embedded in templates?  I don't think there are any
> reasonable arguments one could make, as I as well as other believe that
>
>   #if($total < $max )
>
> Is much better practice than
>
>   #if($total < 100.00)
>
> Because when the application's notion of 'max' changes, off you go finding
> all the uses in the template.  It's the same reason why you use static
> 'constants' in Java and #defines in C (and enums in C++, I guess).
>
> So that's the issue : if you believe that this is a templating system
rather
> than a scripting environment, then is there a reason to represent floating
> point numbers?
>
> geir
>
> >
> > best, wgh
> >
> > Quoting lloyd <su...@twilight-systems.com>:
> >
> >> while i have no opinion re: Revusky on issues of list etiquette and
> >> civility, i have been silently cheering him on when it comes to the
> >> floating point issue.  i think the designer should at least be able to
> >> *identify* a number with decimal points in VTL.
> >>
> >
> > ------------------------------------
> > Will Glass-Husain  <wg...@forio.com>
> > Forio Business Simulations
> > office: (415) 440-7500
> > mobile: (415) 235-4293
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> 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: DECIMAL POINTS (once more with feeling)

Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/5/02 2:50 PM, "Will Glass-Husain" <wg...@forio.com> wrote:

> 
> Well said.  we love Velocity, but this is the number 1 limitation for us.  to
> the template designer, there is no difference between an integer and floating
> point-- why limit one but not the other?  It'd be great if someone were to
> step 
> up to the plate with a patch that would allow this.

There are two aspects to the problem.  I sit on the fence with this issue,
leaning towards the pro-float side.

I am on the pro-float side in that I think that the comparisons should
support floating point arithmetic :

  #if( $total < $limit )

And when I get the parser stuff finished, I am happy put that in so we can
play with it.  I have done it in other projects, and there are few problems.
(The problems come in with people understanding coercion et al...)

What I am not convinced about is

  #if($total < 100.25)

with the reason being the usual that it's bad practice to embed a constant
like that , and not sure there is a need in a system where the data is
supposed to come from elsewhere.

If you remember way back, we really gave a hard stare at numbers in general.
Some believed that any arithmetic should be kept out of Velocity, but it's
clear that simple integer arithmetic is critical for designers to do layout.

That's the crux of the VTL literal issue : do designers need to have
floating point numbers embedded in templates?  I don't think there are any
reasonable arguments one could make, as I as well as other believe that

  #if($total < $max )

Is much better practice than

  #if($total < 100.00)

Because when the application's notion of 'max' changes, off you go finding
all the uses in the template.  It's the same reason why you use static
'constants' in Java and #defines in C (and enums in C++, I guess).

So that's the issue : if you believe that this is a templating system rather
than a scripting environment, then is there a reason to represent floating
point numbers?

geir

> 
> best, wgh
> 
> Quoting lloyd <su...@twilight-systems.com>:
> 
>> while i have no opinion re: Revusky on issues of list etiquette and
>> civility, i have been silently cheering him on when it comes to the
>> floating point issue.  i think the designer should at least be able to
>> *identify* a number with decimal points in VTL.
>> 
> 
> ------------------------------------
> Will Glass-Husain  <wg...@forio.com>
> Forio Business Simulations
> office: (415) 440-7500
> mobile: (415) 235-4293
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DECIMAL POINTS (once more with feeling)

Posted by Will Glass-Husain <wg...@forio.com>.
Well said.  we love Velocity, but this is the number 1 limitation for us.  to 
the template designer, there is no difference between an integer and floating 
point-- why limit one but not the other?  It'd be great if someone were to step 
up to the plate with a patch that would allow this.

best, wgh

Quoting lloyd <su...@twilight-systems.com>:

> while i have no opinion re: Revusky on issues of list etiquette and
> civility, i have been silently cheering him on when it comes to the
> floating point issue.  i think the designer should at least be able to
> *identify* a number with decimal points in VTL.  
> 

------------------------------------
Will Glass-Husain  <wg...@forio.com>
Forio Business Simulations
office: (415) 440-7500
mobile: (415) 235-4293

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>