You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2001/09/01 02:09:01 UTC
Re: floating point types
> or worse "you can use $Var.AnIntProperty in a if, because it's an integer,
> but you can't use $blah.AnDoubleProperty because it's a float"
i have to admit this point pushes me further toward the 'make velocity
handle floats' side of the discussion. it is one thing for a designer to
remember to use '1' and '1.0' differently, but it becomes much less obvious
when $foo.value fetches an integer and $bar.value gets a double.
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/28/01 5:29 PM, "James Maes" <jm...@sportingnews.com> wrote:
>
> On Tuesday 28 August 2001 04:21 pm, you wrote:
>> On 8/29/01 5:02 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
>>> on 8/28/01 12:01 PM, "James Maes" <jm...@sportingnews.com> wrote:
>>>> Why not do something more like perl. A scalar type that is open to what
>>>> ever type needed.
>>>
>>> $scalar.convert("10.1")
>>> $scalar.convert("10,1")
>>
>> Sure. That's perl like... How about
>>
>> $!("10.1")->$#
>>
>> Or something...
>>
>> Geir
>
> I was just thinking of something more like the fact the perl programmers do
> not have to care about which type they want. It's handled for them. I'm did
> not imply syntax, just functionality.
>
>
I knew exactly what you meant :) I actually love Perl, but also love to
make fun of the cryptic code I used to write with it.
VB is the same way with the Variant type.
Geir
Re: floating point types
Posted by James Maes <jm...@sportingnews.com>.
On Tuesday 28 August 2001 04:21 pm, you wrote:
> On 8/29/01 5:02 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
> > on 8/28/01 12:01 PM, "James Maes" <jm...@sportingnews.com> wrote:
> >> Why not do something more like perl. A scalar type that is open to what
> >> ever type needed.
> >
> > $scalar.convert("10.1")
> > $scalar.convert("10,1")
>
> Sure. That's perl like... How about
>
> $!("10.1")->$#
>
> Or something...
>
> Geir
I was just thinking of something more like the fact the perl programmers do
not have to care about which type they want. It's handled for them. I'm did
not imply syntax, just functionality.
--
------------------------------------
|| James Maes
|| Senior Programmer
|| jmaes@sportingnews.com
|| The Sporting News
|| www.sportingnews.com
|| fantasy.sportingnews.com
|| radio.sportingnews.com
------------------------------------
"given enough time and resources we can accomplish anything"
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/29/01 5:02 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
> on 8/28/01 12:01 PM, "James Maes" <jm...@sportingnews.com> wrote:
>
>> Why not do something more like perl. A scalar type that is open to what ever
>> type needed.
>
> $scalar.convert("10.1")
> $scalar.convert("10,1")
Sure. That's perl like... How about
$!("10.1")->$#
Or something...
Geir
Re: floating point types
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 12:01 PM, "James Maes" <jm...@sportingnews.com> wrote:
> Why not do something more like perl. A scalar type that is open to what ever
> type needed.
$scalar.convert("10.1")
$scalar.convert("10,1")
:-)
-jon
Re: floating point types
Posted by James Maes <jm...@sportingnews.com>.
Why not do something more like perl. A scalar type that is open to what ever
type needed.
On Tuesday 28 August 2001 01:45 pm, you wrote:
> > I agree that we are in the gray areas here. However, I don't see why
> > being primitive is so special. Double is also a primitive data type, as
> > well as long, etc, and I can guarantee a -1 for any proposal that wishes
> > to put in explicit distinction of the primitive types. :)
>
> I'm thinking from the point of view of the designer. He will not care
> whether a number is an int or a long, or if it's a float or a double;
> but he may very well be confused why he can't use any numbers that have
> a decimal point in them.
>
> cx
--
------------------------------------
|| James Maes
|| Senior Programmer
|| jmaes@sportingnews.com
|| The Sporting News
|| www.sportingnews.com
|| fantasy.sportingnews.com
|| radio.sportingnews.com
------------------------------------
"given enough time and resources we can accomplish anything"
Re: floating point types
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> I agree that we are in the gray areas here. However, I don't see why being
> primitive is so special. Double is also a primitive data type, as well as
> long, etc, and I can guarantee a -1 for any proposal that wishes to put in
> explicit distinction of the primitive types. :)
I'm thinking from the point of view of the designer. He will not care
whether a number is an int or a long, or if it's a float or a double;
but he may very well be confused why he can't use any numbers that have
a decimal point in them.
cx
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/28/01 4:21 AM, "Lloyd Llewellyn" <su...@twilight-systems.com>
wrote:
>
>> People want floating point values because they are performing programmatic
>> actions that, IMO, should not be done in a template.
>
> People want floats in templates simply because the realm of numbers has
> been artificially divided into floats and integer. Designers AND
> developers simply want to deal with all numbers. Naturally, the
> developer has to be concerned with the distinction between data types,
> but the designer should just be able to deal with numbers, whether
> there's something after the decimal point or not.
It is indeed artificial - but there was quite a debate in the beginning
about the legitimacy of even having integer arithmetic. It was felt by
quite a few people that even integers was too much.
However, I think that we all agree that there are clear needs for basic
integer math for formatting and presentation reasons.
>
>
>> I will
>> always contend that there's something wrong with your app if you require any
>> sort of logical processing in your templates,
>
> I'll take you up on that. The very existence of logical constructs like
> conditionals in the VTL refute your contention.
>
I think that the author you are quoting ( it is jason - can you include that
next time?) was talking about 'business logical processing', rather than
'presentational logical processing'. Of course, we each define those two
terms as we like, but I bet we could agree on a different label for each of
#if( ($rowcount % 10) == 0)
$color = "blue"
#else
$color = "red"
#end
#if( $accountbalance > 0.0 )
$transactionok = true
#else
$transactionok = false
#end
>> Often it is more convenient and expedient to have this
>> processing in templates, but this is certainly no boon to designers.
>
> "Processing" is REQUIRED to render a view. Near the edges of the
> boundary between logic and view there is a grey area where a particular
> logical operation may be designated a view operation or a logic
> operation. That decision is left to the system architect and the
> developer.
>
> In any case, I fail to see how the "float" argument is related at all to
> view / business logic separation. A float is simply a primitive data
> type.
I agree that we are in the gray areas here. However, I don't see why being
primitive is so special. Double is also a primitive data type, as well as
long, etc, and I can guarantee a -1 for any proposal that wishes to put in
explicit distinction of the primitive types. :)
>
>> I am definitely against adding floating point processing.
>
> What exactly do you mean by "processing"? All those of us in the "yes
> floats" camp are asking for is the ability of VTL to recognize a float
> when it sees one.
>
> I agree with you that Velocity should not become a general-purpose
> scripting language; the fact that it's not is one of its strengths. I
> just don't believe we should become so paranoid about it that something
> as simple as recognizing the float data type becomes scary.
It's not 'scary' to me. (Remember, I am in many ways for the idea...) The
issue to me is "Is this needed for a large enough segment of the Velocity
community to warrant it?", which I think is a fair thing to be concerned
about. This question seems to be always the case - if you remember back a
ways, there was serious pushback on magical reference processing until we
evolved the idea into a general event handling system. That is something
that benefitted all, including Leon and his XML needs.
Geir
Re: floating point types
Posted by "Henning P. Schmiedehausen" <ma...@hometree.net>.
"Tim Colson" <tc...@cisco.com> writes:
>As a Designer, I'd expect that as long as $a and $b are numbers, this should
>be legal:
>#if ($a > $b)
> A is bigger than B!
>#end
Yes!
[...]
>This brings us back to the Designer - trying to compare $a and $b which she
>thinks both are number-like-thingies.
>Now try to explain to her why sometimes she can compare the number-thingies
>using ">" and sometimes she has to use
>"$NumberCompareTool.IsAGreaterThanB($a, $b)".
Now try to explain her, that
#if ( $a > 0 )
foo
#end
does not work if $a is a hmmm, special, kind of number. Say a short.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
Re: floating point types - Designer Issue
Posted by Nick Bauman <ni...@cortexity.com>.
>
>> 1) A template language with just enough programming language features
>> to not have to modify the Java code for every small change in the
>> template, and to be able to do things like loop through a list of
>> items, have a different display for 0 items versus N items, etc.
>
> You sissy! Make a utility object and put it in the context! (Sorry
> folks, couldn't resist)
And I agree, but...
> I will state my opinion again: The ability to recognize non-decimal
> numbers does not threaten your business logic.
In the strictest sense of the concept, you are correct, however; practise
bears out that floating point math in the Context is
a) Elusively benefical, often leading to the exposure of business logic in
the view.
b) Unecessary to do real world programming with emphasis toward a clean
seperation of the MV&C
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
SMS: 6122327120@voicestream.net
Home: (612) 522-0165
Re: floating point types - Designer Issue
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> 1) A template language with just enough programming language features to
> not have to modify the Java code for every small change in the template,
> and to be able to do things like loop through a list of items, have a
> different display for 0 items versus N items, etc.
You sissy! Make a utility object and put it in the context! (Sorry
folks, couldn't resist)
I will state my opinion again: The ability to recognize non-decimal
numbers does not threaten your business logic.
Re: floating point types - Designer Issue
Posted by Kyle Cordes <ky...@kylecordes.com>.
> >Maybe we should get rid of ">" in order to make things easier to
understand.
> >:-)
>
> If you get rid of < <= == != => > you can get rid of conditionals,
too.
>
> Fine with me, we now start to get a template language, not a
> programming language. If you can program Towers of Hanoi in it, it
> qualifies for me as a programming language.
I see a difference between:
1) A template language with just enough programming language features to
not have to modify the Java code for every small change in the template,
and to be able to do things like loop through a list of items, have a
different display for 0 items versus N items, etc.
2) A template language with enough language features that someone might
think that putting logic there is a good idea.
Somewhat oddly, I think a key attribute of a good template system is
that it's *painful* to try to do much logic in it. I've seen what often
happens (JSP, ASP) when it's easy to do so.
[ Kyle Cordes * kyle@kylecordes.com * www.kylecordes.com ]
[ Developer, Consultant, Trainer: Java, Delphi, ASTA, etc.]
[ Visit the site for articles, links, BDE Alternatives ]
[ Guide, JBuilder Open Tools, and a Delphi Wiki, and more ]
Re: floating point types - Designer Issue
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/2/01 11:11 AM, "Henning P. Schmiedehausen" <ma...@hometree.net>
wrote:
> If you get rid of < <= == != => > you can get rid of conditionals, too.
>
> Fine with me, we now start to get a template language, not a
> programming language. If you can program Towers of Hanoi in it, it
> qualifies for me as a programming language.
>
> Regards
> Henning
I think I could write a Towers of Hanoi with just $variable references.
Should we also get rid of those as well?
:-)
I just love your minimalist ideas.
-jon
Re: floating point types - Designer Issue
Posted by "Henning P. Schmiedehausen" <ma...@hometree.net>.
Jon Stevens <jo...@latchkey.com> writes:
>Maybe we should get rid of ">" in order to make things easier to understand.
>:-)
If you get rid of < <= == != => > you can get rid of conditionals, too.
Fine with me, we now start to get a template language, not a
programming language. If you can program Towers of Hanoi in it, it
qualifies for me as a programming language.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
Re: floating point types - Designer Issue
Posted by "Jeroen C. van Gelderen" <je...@vangelderen.org>.
Jon Stevens wrote:
> on 8/29/01 11:39 AM, "Tim Colson" <tc...@cisco.com> wrote:
>
>
>>=============
>>Temperature Comparison<BR>
>>CurrentTemp = $currentTemp<BR>
>>HighTemp = $highTemp<BR>
>>HistoricalAverageTemp = $historicalAverageTemp<BR>
>>
>>Is current higher than the avg?
>>#if ($currentTemp > $historicalAverageTemp) YES #else NO #end
>>Is hightemp higher than the avg?
>>#if ($highTemp > $historicalAverageTemp) YES #else NO #end
>>=============
>>
>
> This is going to get into a best practices thing again.
>
> Temperature Comparison<BR>
> CurrentTemp = $temp.Current<BR>
> HighTemp = $temp.High<BR>
> HistoricalAverageTemp = $temp.HistoricalAverage<BR>
>
> Is current higher than the avg?
> #if ($bo.compare($temp.Current, $temp.High)) YES #else NO #end
> Is hightemp higher than the avg?
> #if ($bo.compare($temp.highTemp, $temp.HistoricalAverage)) YES #else NO
> #end
Heu, I take it that you mean that the added complexity and decreased
readability by the indirection trough $bo is a better practice? This
sounds like separation of concerns gone mad!
Surely in this case equality is a property of the arguments (objects)
involved and not a property that is defined by logic in an external $bo
object? What benefit do you get out of giving the business logic the
ability to change that? How can you change the behaviour of compare
without confusing its users?
Another problem: from an programmer's point of view the 'compare' method
is misnamed; The contract of compare does not imply a boolean result yet
you are using it inside an if statement. This goes against the
established contract of the all too similar Java compareTo method in
java.lang.Comparable and java.math.BigInteger to name a few. If you
insist on indirecting trough $bo, the method should be named
appropriately: isEqual or equals.
What are the advantages of using a 'business object' here?
Cheers,
Jeroen
RE: floating point types - Designer Issue
Posted by Tim Colson <tc...@cisco.com>.
Howdy folks - some more good clean fun :-)
Jon wrote:
> This is going to get into a best practices thing again.
....snip...
> #if ($bo.compare($temp.Current, $temp.High)) YES #else NO #end
I disagree - "best practices" is not the issue I'm discussing.
I already noted that there are infinite alternatives available. Jon's
suggested $bo.compare() is one of them...albeit a goofy and confusing one
IMHO. ;-)
But try for a minute to ignore religious debates about logic separation and
focus on the comparison itself. Please allow that at least for the sake of
this discussion that the Designer is using a comparison that they are fully
justified to use. Imagine for a second that Jon Stevens himself has agreed
that the Designer should make the comparison between the two thingies in
question.
Now, as a Developer, explain why the following yields the 'wrong' result.
#if ($a > $b) YES #else wookie #end
REASON: Velocity 1.1 cannot compare the JAVA variable types of $a and $b
correctly.
WORKAROUND1: The Developer will compare them (correctly), and provide a new
item in the context with a value (boolean) that Velocity 1.1 can interpret
correctly.
#if ($a_greaterthan_b) YES #else wookie #end
WORKAROUND2: The Developer will provide a utility for dynamically comparing
(again correctly) two numbers.
#if ($util.a_greaterthan_b($a,$b)) YES #else wookie #end
Yikes - worded thataway - comparing $a and $b sounds rather like a bug.
<grin>
Jon wrote:
> Maybe we should get rid of ">" in order to make things easier to
> understand.
Yes, indeed, it was a slippery slope giving the Designer expression
evaluation. :-)
FYI - a popular Perl template package (HTML::Template) has NOT given
expression evaluation to the Designer. Its IF directive can only test for
boolean True/False.
<TMPL_IF NAME="BOOL">
Some text that only gets displayed if BOOL is true!
</TMPL_IF>
(snipped from the http://www.perldoc.com/cpan/HTML/Template.html )
With Velocity the cat is already out of the bag and expression evaluation is
allowed in the template. Personally, I'm quite fond of that; however, I'd
just like it to be able to compare numbers to other numbers, regardless of
race, creed, decimal point, or JAVA type. <grin>
BTW - I'll respect the moratorium now... I've had my last say, and despite
whatever surly responses I might or might not get - I won't bother the list
on this topic anymore....but I do have a thing or two to say about that
"#include and servlets" topic <big facetious grin>
Cheers,
Timothy
Re: floating point types - Designer Issue
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/29/01 11:39 AM, "Tim Colson" <tc...@cisco.com> wrote:
> =============
> Temperature Comparison<BR>
> CurrentTemp = $currentTemp<BR>
> HighTemp = $highTemp<BR>
> HistoricalAverageTemp = $historicalAverageTemp<BR>
>
> Is current higher than the avg?
> #if ($currentTemp > $historicalAverageTemp) YES #else NO #end
> Is hightemp higher than the avg?
> #if ($highTemp > $historicalAverageTemp) YES #else NO #end
> =============
This is going to get into a best practices thing again.
Temperature Comparison<BR>
CurrentTemp = $temp.Current<BR>
HighTemp = $temp.High<BR>
HistoricalAverageTemp = $temp.HistoricalAverage<BR>
Is current higher than the avg?
#if ($bo.compare($temp.Current, $temp.High)) YES #else NO #end
Is hightemp higher than the avg?
#if ($bo.compare($temp.highTemp, $temp.HistoricalAverage)) YES #else NO
#end
Maybe we should get rid of ">" in order to make things easier to understand.
:-)
-jon
RE: floating point types - Designer Issue
Posted by Tim Colson <tc...@cisco.com>.
Howdy again folks -
And now just for fun - so I too can be bashed <grin>...here's a theoretical
example of comparison that would barf.... and YES, it could be fixed in
zillion ways... but try to put on your "Empathize with the Designer" hat
when reading this:
----------------
My name is Phrederina and I'm a Designer with a problem.
I have a template thingy using this Velocity stuff. I'm building a page
which displays weather information. The Developer dude says that I have a
thingy called $currentTemp which he says will give me degrees like 90.5 and
another thingy called $historicalAverageTemp in degrees too, like 85 or 90,
etc.
My template looks like this:
=============
Temperature Comparison<BR>
CurrentTemp = $currentTemp<BR>
HighTemp = $highTemp<BR>
HistoricalAverageTemp = $historicalAverageTemp<BR>
Is current higher than the avg?
#if ($currentTemp > $historicalAverageTemp) YES #else NO #end
Is hightemp higher than the avg?
#if ($highTemp > $historicalAverageTemp) YES #else NO #end
=============
The output looks like this:
=============
Temperature Comparison
CurrentTemp = 98.5
HighTemp = 99
HistoricalAverageTemp = 85
Is current higher than the avg? NO ---> HUH????
Is hightemp higher than the avg? YES
=============
QUESTION: Why doesn't this work as I expect??? I don't understand this
Velocity stuff! 98.5 is greater than 85 so why is does the comparison say
"NO"??? Is this a bug? Do Wookie's really live on Endor? This MAKES NO
SENSE!!! Please help!
FYI - My [really smart and handsome] Developer says the java code he writes
looks like this, but I don't know what the heck it means... I guess 98.5f
means it's in Fahrenheit.
// Testing float vs. integer comparison
context.put("currentTemp", new Float(98.5f) );
context.put("historicalAverageTemp", new Integer(85) );
context.put("highTemp", new Integer(99) );
Other than this weirdness - Velocity ROCKS! I hated that JSP stuff. I was
always f'n it up.
Thanks in advance for your help!
- Phrederina
Re: floating point types
Posted by Bojan Smojver <bo...@binarix.com>.
"Geir Magnusson Jr." wrote:
>
> Can we give this thread a week's moratorium or something?
>
> Here's why - each side has some good arguments, at least I think so.
> However, I think that every point has been made, so maybe a bit of
> contemplation would be good.
>
> This is just a suggestion - this is a free and open forum, so people can say
> what that want, so if you don't agree with my suggestion, feel free to keep
> going. I just think further battery of this deceased equine is only going
> to make it harder to find a solution and further, embitter people.
>
> Geir
+1.0 for the suggestion ;-)
Bojan
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Can we give this thread a week's moratorium or something?
Here's why - each side has some good arguments, at least I think so.
However, I think that every point has been made, so maybe a bit of
contemplation would be good.
This is just a suggestion - this is a free and open forum, so people can say
what that want, so if you don't agree with my suggestion, feel free to keep
going. I just think further battery of this deceased equine is only going
to make it harder to find a solution and further, embitter people.
Geir
RE: floating point types
Posted by Tim Colson <tc...@cisco.com>.
> Why does the designer even know they are number-like-thingies?
That's the point, Jon. Take the mental leap with me. Assume it's true, and
therefore the question at hand is not "why is the Designer doing the
comparison" it is instead about "Why is the comparison not returning an
expected result?" ;-)
GIVEN: The Developer tells the Desginer - "$a and $b are numbers".
GIVEN: The Designer knows that $a and $b are number-like-thingies.
GIVEN: The Designer wants to compare $a to $b for various design reasons.
THEREFORE: The Designer assumes the following Velocity code will work:
#if ($a > $b) yes #else wookie #end
PROBLEM: $a > $b gives the Designer "wookie" but that doesn't make logical
sense.
Even less sense is made when the Developer tells the Designer, "Oh, yeah,
that won't work... $a is an integer number and $b is a floating point
number."
The Designer then says, "Uh, I thought you said they were numbers? That
seems goofy that I can't compare them - makes no sense."
- Phrederina (aka Tim)
Re: floating point types
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/29/01 11:36 AM, "Tim Colson" <tc...@cisco.com> wrote:
> This brings us back to the Designer - trying to compare $a and $b which she
> thinks both are number-like-thingies.
>
> Now try to explain to her why sometimes she can compare the number-thingies
> using ">" and sometimes she has to use
> "$NumberCompareTool.IsAGreaterThanB($a, $b)".
Why does the designer even know they are number-like-thingies?
-jon
RE: floating point types
Posted by Tim Colson <tc...@cisco.com>.
I'm enjoying the thread; although some arguments wander away from the real
issue.
Here's the way I see things when I put on my Designer hat: Numbers, Strings,
Dates.
A number is a number is a number.
(I write a lot of Perl, and the hassle-free dictum that numbers are simply
numbers means I can add an Integer, float, double, and even a "3.0" string
and it all just works.)
As a Designer, I'd expect that as long as $a and $b are numbers, this should
be legal:
#if ($a > $b)
A is bigger than B!
#end
A lot of the arguments thus far have been challenges to show an example of
why $a or $b must be non-integer, and when someone shows such an example
from the "Real World" - somebody barks about how the comparison shouldn't be
in the view layer in the first place...and so that's why floats shouldn't be
allowed. Meanwhile the sane and logical amongst us I _hope_ are scratching
our heads and thinking about the inherent logical fallacies
http://encarta.msn.com/find/Concise.asp?ti=02E2A000 and how that is a
completely different and religiously charged MVC argument.
For the sake of discussing number comparison in Velocity - can we please
assume that there is at least one case where the comparison DOES belong in
the template and the two number thingies to be compared are of differing
JAVA number types than int?
This brings us back to the Designer - trying to compare $a and $b which she
thinks both are number-like-thingies.
Now try to explain to her why sometimes she can compare the number-thingies
using ">" and sometimes she has to use
"$NumberCompareTool.IsAGreaterThanB($a, $b)".
Hmmm... Chewbacca is a Wookie who lives on Endor.... that MAKES NO SENSE!
;-)
Cheers,
Timo
Re: floating point types
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> How about you show me an example of what you're trying to do. I bet I can
> give you a reason why it shouldn't be in a template. If I can see one of
> your examples I may able to deliver a more compelling argument.
A very simple, if perhaps not compelling argument:
My first Velocity application - I had a list of objects that contained a
float value that I wanted to display in a table. If the float value was
zero, I didn't want to display "0.0", just a blank space.
It was a month or two ago, so I don't recall the exact code, but testing
the float for 0 didn't work. For awhile I just forgot about it and
displayed the zeroes. Eventually I figured out that Velocity did not
understand the float data type, so I had to go through some gyrations to
get this to work.
This is clearly in the view domain. My object does not need an
"isZero()" method. I don't need to drag another object into the
equation (MyTool.IsThisDangFloatZero() :-)). I shouldn't have to cast
this primitive data type to another type (string) and compare to "0.0".
VTL simply needs to understand the float data type in order to correctly
render the page.
> #if ($total > $overdraught) No more money for you bad customer! #end
Yes, here you're using logic in VTL which is bad. But it's not the
fault of the float data type, it's the fault of your designer. How is
this any different than if the money amounts were integer, and you
performed the above operations? This is not a hypothetical case - I'm
working on a budgeting application right now where all money amounts are
integers (pennies).
> I think cautious would be more accurate a word. As if we add float people
> will inevitably ask for comparisons for every primitive type and I
> definitely don't want to see that.
What are the primitive types that a designer needs? Numbers, strings,
boolean (any others?). But I believe numbers should include
non-integral numbers.
Re: floating point types
Posted by Nick Bauman <ni...@cortexity.com>.
Jon,
> This also has the "feature" of allowing you to redefine the business
> logic without having to change the templates. For example, if the low
> and high needed to be switched or something.
>
> -jon
Exactly.
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
Home: (612) 522-0165
Is Velocity Implementation == MVC Implementation? was re: floating point types
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
--- Jon Stevens <jo...@latchkey.com> wrote:
>
> In other words, we should modify Velocity because your app has
> "design
> flaws".
>
> Hmmm...
>
Nope, not what I was saying at all. :) (Read on for why) Remember
that I really don't care I was just giving a "real world" example from
my trenches where numbers that happen to have floating point precision
are involved in what to me is completely divorced from business logic.
> In other words, if we provided context tools that were "commonly"
> distributed with Velocity, the issue would be resolved without having
> to
> modify VTL.
>
> Hmmm...
I think the issue we are batting around here is that numbers are
dealt with in the velocity "core" (for lack of a better term). The
numbers happen to be integers, however I see no compelling reason that
they have to be (The BigNumber idea is compelling). There seems to be a
disagreement in regards to "needing" floats in an MVC architecture,
which I would argue (not that I develop or design the velocity core at
all) is not central to Velocity per say.
From the web site I quote the following text which to me says that
Velocity Implementation != MVC Implementation (or according to the text
below, at least it does not have to be). MVC is good, however limiting
velocity's implementation of numbers for the sole purpose of making it
harder to not do MVC is a little silly. :)
=====
>From http://jakarta.apache.org/velocity/
=====
What is Velocity?
Velocity is a Java-based template engine. It permits anyone to use
the simple yet powerful template language to reference objects
defined in Java code.
When Velocity is used for web development, Web designers can work
in parallel with Java programmers to develop web sites according to
the Model-View-Controller (MVC) model, meaning that web page
designers can focus solely on creating a site that looks good, and
programmers can focus solely on writing top-notch code. Velocity
separates Java code from the web pages, making the web site more
maintainable over the long run and providing a viable alternative
to Java Server Pages (JSPs) or PHP.
Velocity's capabilities reach well beyond the realm of web sites;
for example, it can generate SQL and PostScript and XML (see Anakia
for more information on XML transformations) from templates. It can
be used either as a standalone utility for generating source code
and reports, or as an integrated component of other systems.
Velocity also provides template services for the Turbine web
application framework. Velocity+Turbine provides a template service
that will allow web applications to be developed according to a
true MVC model.
=====
In reality I am perfectly willing to use context tools for number
support in velocity if that is the resolution of this long thin thread.
;) The power and agility that velocity gives us far outweighs any
annoyances.
I personally would rather see access into the parse tree when
events are caught in an EventManager than native floating point number
support. It would enable me to get better line/column error messages to
be integrated into some of the tools that I am working with. When I
have "down" time I am looking into patching some of this in and
contributing it.
Again, thanks to ALL who have made Velocity what it is today. I
couldn't do my job without it.
-Brian
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: floating point types
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 7:16 PM, "Brian Lloyd-Newberry" <ne...@yahoo.com> wrote:
>
> Yes, I agree with the $interval.inInterval( ) idea as a good
> replacement with a small side step or two.
>
> Firstly, it is not possible in my current architecture without some
> work. I am using what amounts to an iterator over a result set for the
> interval object and there is no way to attach a method to that
> "object". (These "objects" are really hash tables with some other glue
> that are auto generated from a result set and other data sources). I
> can see that as a "design flaw", however in this case it is a sacrifice
> I am willing to make for the single report on this one page and for the
> tradeoff in lines of code written. A tradeoff of perfection for
> completion before the sun burns out. :)
In other words, we should modify Velocity because your app has "design
flaws".
Hmmm...
> Secondly, it could be argued that I really don't care as a designer
> of business logic where the $result goes or even how it is presented
> (remember the pixel on/off statement from earlier this thread).
Exactly, the pixel on/off statement is resolved just for that reason. :-)
> I would
> argue that the display of this data is solidly in the presentation
> logic realm. I can see a context tool of the type $number.between(
> $low, $high, $n ) or $number.inRangeInclusive( $low, $high, $n ) as
> beautifying things for the developer although yet another thing that
> they have to learn to do the same thing they could with a "common"
> velocity syntax.
In other words, if we provided context tools that were "commonly"
distributed with Velocity, the issue would be resolved without having to
modify VTL.
Hmmm...
-jon
Re: floating point types
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
Yes, I agree with the $interval.inInterval( ) idea as a good
replacement with a small side step or two.
Firstly, it is not possible in my current architecture without some
work. I am using what amounts to an iterator over a result set for the
interval object and there is no way to attach a method to that
"object". (These "objects" are really hash tables with some other glue
that are auto generated from a result set and other data sources). I
can see that as a "design flaw", however in this case it is a sacrifice
I am willing to make for the single report on this one page and for the
tradeoff in lines of code written. A tradeoff of perfection for
completion before the sun burns out. :)
Secondly, it could be argued that I really don't care as a designer
of business logic where the $result goes or even how it is presented
(remember the pixel on/off statement from earlier this thread). I would
argue that the display of this data is solidly in the presentation
logic realm. I can see a context tool of the type $number.between(
$low, $high, $n ) or $number.inRangeInclusive( $low, $high, $n ) as
beautifying things for the developer although yet another thing that
they have to learn to do the same thing they could with a "common"
velocity syntax.
Again, just my 2c. :)
-Brian
--- Jon Stevens <jo...@latchkey.com> wrote:
> on 8/28/01 1:58 PM, "Brian Lloyd-Newberry" <ne...@yahoo.com> wrote:
>
> > #foreach( $interval in $intervals )
> > <TR>
> > #if( $result >= $interval.low && $result <= $interval.high )
>
> I would write this as something like:
>
> #if ($interval.doCompare($result))
>
> You can pick the method name that sounds best for you.
>
> And put the business logic of checking into the $interval object
> instead of
> in the template.
>
> This also has the "feature" of allowing you to redefine the business
> logic
> without having to change the templates. For example, if the low and
> high
> needed to be switched or something.
>
> -jon
>
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/29/01 5:24 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
> on 8/28/01 1:58 PM, "Brian Lloyd-Newberry" <ne...@yahoo.com> wrote:
>
>> #foreach( $interval in $intervals )
>> <TR>
>> #if( $result >= $interval.low && $result <= $interval.high )
>
> I would write this as something like:
>
> #if ($interval.doCompare($result))
>
> You can pick the method name that sounds best for you.
>
> And put the business logic of checking into the $interval object instead of
> in the template.
>
> This also has the "feature" of allowing you to redefine the business logic
> without having to change the templates. For example, if the low and high
> needed to be switched or something.
I was just about to fire off a message with pretty much the same thing, so I
will just add to this.
I would do something like
public boolean inRange( <whatever type $result is> )
So that way you could, like jon says, keep the BL in there - for example,
what do you mean by bounded by?
low <= result <= high
low < result <= high
low <= result < high
low < result < high
Can you imagine chasing this bugger down throughout a set of templates?
Geir
Re: floating point types
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 1:58 PM, "Brian Lloyd-Newberry" <ne...@yahoo.com> wrote:
> #foreach( $interval in $intervals )
> <TR>
> #if( $result >= $interval.low && $result <= $interval.high )
I would write this as something like:
#if ($interval.doCompare($result))
You can pick the method name that sounds best for you.
And put the business logic of checking into the $interval object instead of
in the template.
This also has the "feature" of allowing you to redefine the business logic
without having to change the templates. For example, if the low and high
needed to be switched or something.
-jon
Re: floating point types
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
--- Jason van Zyl <jv...@apache.org> wrote:
> On 8/28/01 4:21 AM, "Lloyd Llewellyn"
> <su...@twilight-systems.com>
> wrote:
>
>
> > In any case, I fail to see how the "float" argument is related at
> all to
> > view / business logic separation. A float is simply a primitive
> data
> > type.
>
> How about you show me an example of what you're trying to do. I bet I
> can
> give you a reason why it shouldn't be in a template. If I can see one
> of
> your examples I may able to deliver a more compelling argument.
>
I have an example that I just ran into with a new designer this
morning.
Say we have a collection of intervals called, strangely enough,
$intervals. Now an interval has 2 attributes called "low" and "high"
which are float or double (either of which proves the point).
Additionally assume that we have a value called $result which is a
float or a double or actually any numeric value (we'll avoid bringing
in other primitives here for now though).
Here is a chunk of Velocitized HTML that completes the example example.
<TABLE>
<TR>
<TD> </TD>
<TD>low</TD>
<TD>high</TD>
</TR>
#foreach( $interval in $intervals )
<TR>
#if( $result >= $interval.low && $result <= $interval.high )
<TD>Result</TD>
#else
<TD> </TD>
#end
<TD>$interval.low</TD>
<TD>$interval.high</TD>
</TR>
#end
</TABLE>
-Brian
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: floating point types
Posted by Jason van Zyl <jv...@apache.org>.
On 8/28/01 4:21 AM, "Lloyd Llewellyn" <su...@twilight-systems.com>
wrote:
>
>> I will
>> always contend that there's something wrong with your app if you require any
>> sort of logical processing in your templates,
>
> I'll take you up on that. The very existence of logical constructs like
> conditionals in the VTL refute your contention.
I put logical constructs in the original version of velocity so that it was
compatible with WebMacro not because I thought they were good.
>
>> Often it is more convenient and expedient to have this
>> processing in templates, but this is certainly no boon to designers.
>
> "Processing" is REQUIRED to render a view. Near the edges of the
> boundary between logic and view there is a grey area where a particular
> logical operation may be designated a view operation or a logic
> operation. That decision is left to the system architect and the
> developer.
Nothing is stopping you from using a context tool. You are free to do
whatever you want.
> In any case, I fail to see how the "float" argument is related at all to
> view / business logic separation. A float is simply a primitive data
> type.
How about you show me an example of what you're trying to do. I bet I can
give you a reason why it shouldn't be in a template. If I can see one of
your examples I may able to deliver a more compelling argument.
>
>> I am definitely against adding floating point processing.
>
> What exactly do you mean by "processing"?
#set ($total = $total + $amount)
#if ($total > $overdraught) No more money for you bad customer! #end
> All those of us in the "yes
> floats" camp are asking for is the ability of VTL to recognize a float
> when it sees one.
Yes, I realize that. But why do you want floats recognized? What do you
want to do with it in the template.
> I agree with you that Velocity should not become a general-purpose
> scripting language; the fact that it's not is one of its strengths. I
> just don't believe we should become so paranoid about it that something
> as simple as recognizing the float data type becomes scary.
I think cautious would be more accurate a word. As if we add float people
will inevitably ask for comparisons for every primitive type and I
definitely don't want to see that.
>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
Re: floating point types
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> People want floating point values because they are performing programmatic
> actions that, IMO, should not be done in a template.
People want floats in templates simply because the realm of numbers has
been artificially divided into floats and integer. Designers AND
developers simply want to deal with all numbers. Naturally, the
developer has to be concerned with the distinction between data types,
but the designer should just be able to deal with numbers, whether
there's something after the decimal point or not.
> I will
> always contend that there's something wrong with your app if you require any
> sort of logical processing in your templates,
I'll take you up on that. The very existence of logical constructs like
conditionals in the VTL refute your contention.
> Often it is more convenient and expedient to have this
> processing in templates, but this is certainly no boon to designers.
"Processing" is REQUIRED to render a view. Near the edges of the
boundary between logic and view there is a grey area where a particular
logical operation may be designated a view operation or a logic
operation. That decision is left to the system architect and the
developer.
In any case, I fail to see how the "float" argument is related at all to
view / business logic separation. A float is simply a primitive data
type.
> I am definitely against adding floating point processing.
What exactly do you mean by "processing"? All those of us in the "yes
floats" camp are asking for is the ability of VTL to recognize a float
when it sees one.
I agree with you that Velocity should not become a general-purpose
scripting language; the fact that it's not is one of its strengths. I
just don't believe we should become so paranoid about it that something
as simple as recognizing the float data type becomes scary.
Re: floating point types
Posted by Attila Szegedi <sz...@freemail.hu>.
To be precise, "goto" is both a reserved AND prohibited word in Java,
meaning it has no semantics. The closest construct to it is a labeled break.
Attila.
----- Original Message -----
From: "Paul Sorenson" <pa...@metrak.com>
To: <ve...@jakarta.apache.org>
Sent: 2001. augusztus 28. 12:31
Subject: Re: floating point types
> Just do it.
>
> If your own personal view of the world prohibits the use of floating point
> numbers then you are free not to use them. Just like goto statements in
> Java.
>
> Paul
>
>
Re: floating point types
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 3:31 AM, "Paul Sorenson" <pa...@metrak.com> wrote:
> Just do it.
>
> If your own personal view of the world prohibits the use of floating point
> numbers then you are free not to use them. Just like goto statements in
> Java.
>
> Paul
Just like JSP people shouldn't use scriptlets, but they do.
-jon
Re: floating point types
Posted by Paul Sorenson <pa...@metrak.com>.
Just do it.
If your own personal view of the world prohibits the use of floating point
numbers then you are free not to use them. Just like goto statements in
Java.
Paul
RE: floating point types
Posted by Ewan Makepeace <ew...@yahoo.com>.
It is dawning on me from this discussion of floating point types, that I do
not, in fact, understand the MVC model as well as I thought, or at least
it's use in a Velocitry scenario. The following probably reflects my lack of
experience, but I am genuinly curious as to what is the 'best practice' for
these sorts of problems:
Saimon [below] suggests that most data to be presented in a template be
offerred as strings. This would certainly rigidly enforce the 'View' part,
if all presented data [and presumably only that data] is present in the
context but doesn't this introduce horribly tight coupling, and reduce the
value of the MVC approach?
Example: I have a business object 'invoice', and a template that displays
that invoice. One of the attributes of the invoice object is a 'customer'
object, which has address attributes among other things. Another attribute
is 'invoiceLines', a collection of invoiceLine' objects.
Approach #1: I put the invoice object in the context, and pass it to the
template for processing. The template would use methods such as
invoice.Customer.Address1 and invoiceLine.PriceEA to retrieve information
from the business objects, and display it. [Note that PriceEA might return a
float number]
Approach #2: I write some sort of display wrapper class to take the relevant
data from the business object and put it in the context for the template to
use. Thus the template can directly access information [presumably as
strings] such as customerAddress1 and invoiceTotal. [Invoice lines are
presumably still a collection of objects].
Using Approach 1 has the advantage that both business objects and template
can be modified without undue affects of the other [object oriented, loose
coupling]. In particular the template could be improved to show extra
information without modifying any Java code [programmer not required].
It has the disadvantage that if the interface of the business object changes
[ie customer renamed to invoiceCustomer] not only will the template break,
but it will not be caught by the compiler. There is also the danger of the
template designer having access to object methods that change or side effect
the data.
Using Approach 2 has the advantage that the template interface is
essentially defined in Java, so any change will be caught by the compiler.
However the page designer and programmer have to agree in advance exactly
what data is required by the template. In addition many extra display
classes are required to load the context for each template. Finally any
changes to the template require corresponding changes to the Java code.
Personally I find this tight coupling unattractive and I believe that it
negates most of the benefits of separating display and logic.
Finally consider the example of the invoice total. Is it permissible for the
template to compute the total of the invoice lines and diaplay it, or is
this a gross abuse of the MVC principle? Must the invoice object have a
total method? What if later someone requests an average value, or a line
count value? All these things are easily computed from the object data, but
must we pull in a programmer to add new methods to the business objects to
satisfy the requests? [This is a genuine question, I am curious how people
handle these issues currently].
rgds,
Ewan
-----Original Message-----
From: Saimon Moore [mailto:smoore@serikat.es]
Sent: Tuesday, August 28, 2001 5:25 PM
To: velocity-user@jakarta.apache.org
Subject: RE: floating point types
I agree with you, but an int can be used to control simple basic operations
within a template for presentation purposes, data that comes from the
business logic, in general , is presented as strings.
Floats, on the other hand, 'suggest' actual data (application data i.e. $ &
cents) as opposed to variables for presentation purposes (I could be
forgetting some other use here). Any calculations based on application data
shouldn't IMO be done in the view. They should be presented after
calculation to the view as strings.
I hope that made some sense.
As I said before, there are probably very valid situations for which float
support should exist in velocity, I just don't think that it's valid for use
with MVC web apps (even if it only suggests bad practice).
Saimon
> Akhm. Any web site that processes purchase orders might need to deal with
> cents in a dollar, be it JSP or Velocity. The template example you
submitted
> is no more or less anti- or pro-MVC if these variables are floats instead
of
> ints.
>
> Attila.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
RE: floating point types
Posted by Saimon Moore <sm...@serikat.es>.
I agree with you, but an int can be used to control simple basic operations
within a template for presentation purposes, data that comes from the
business logic, in general , is presented as strings.
Floats, on the other hand, 'suggest' actual data (application data i.e. $ &
cents) as opposed to variables for presentation purposes (I could be
forgetting some other use here). Any calculations based on application data
shouldn't IMO be done in the view. They should be presented after
calculation to the view as strings.
I hope that made some sense.
As I said before, there are probably very valid situations for which float
support should exist in velocity, I just don't think that it's valid for use
with MVC web apps (even if it only suggests bad practice).
Saimon
> Akhm. Any web site that processes purchase orders might need to deal with
> cents in a dollar, be it JSP or Velocity. The template example you
submitted
> is no more or less anti- or pro-MVC if these variables are floats instead
of
> ints.
>
> Attila.
Re: floating point types
Posted by Attila Szegedi <sz...@freemail.hu>.
Akhm. Any web site that processes purchase orders might need to deal with
cents in a dollar, be it JSP or Velocity. The template example you submitted
is no more or less anti- or pro-MVC if these variables are floats instead of
ints.
Attila.
----- Original Message -----
From: "Saimon Moore" <sm...@serikat.es>
To: <ve...@jakarta.apache.org>
Sent: 2001. augusztus 28. 10:28
Subject: RE: floating point types
> I tend to agree with not adding floating point processing! IMO, for web
> application it's definetly anti-MVC because it encourages (unwittingly
> perhaps in some cases) code like
>
> #if ($Variables.Sales > $Variables.SalesTarget) something #end.
>
> with does not belong in the view (and reminds me of a three letter
scripting
> language that begins with J and ends with P).
>
<snip/>
Re: floating point types
Posted by Jason van Zyl <jv...@apache.org>.
On 8/28/01 4:28 AM, "Saimon Moore" <sm...@serikat.es> wrote:
> I tend to agree with not adding floating point processing! IMO, for web
> application it's definetly anti-MVC because it encourages (unwittingly
> perhaps in some cases) code like
>
> #if ($Variables.Sales > $Variables.SalesTarget) something #end.
Exactly. Or 'Bingo' as Jon would say ;-)
> with does not belong in the view (and reminds me of a three letter scripting
> language that begins with J and ends with P).
>
> On the other hand since velocity these days is not only being used for web
> apps (code generation etc..) and someone has gone ahead and written the
> floating-point support,
Yes, but I think code generation is a task initiated by a programmer so the
template tend to get a little funkier, like the torque templates. But we do
everything we need to do in torque with context tools and properties.
> (and in the interest of satisfying both appetites),
> why not introduce the code to velocity and add a property (flag) to
> enable/disable floating point support in velocity.props.
>
> This is a tricky question because thinking it over again, we should be
> trying to enforce MVC, and if you give people the option....
>
> ..but then again they have J?P for that....
> :)
>
> Saimon
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/28/01 4:28 AM, "Saimon Moore" <sm...@serikat.es> wrote:
> I tend to agree with not adding floating point processing! IMO, for web
> application it's definetly anti-MVC because it encourages (unwittingly
> perhaps in some cases) code like
>
> #if ($Variables.Sales > $Variables.SalesTarget) something #end.
>
> with does not belong in the view (and reminds me of a three letter scripting
> language that begins with J and ends with P).
>
> On the other hand since velocity these days is not only being used for web
> apps (code generation etc..) and someone has gone ahead and written the
> floating-point support, (and in the interest of satisfying both appetites),
> why not introduce the code to velocity and add a property (flag) to
> enable/disable floating point support in velocity.props.
That's a touch yecchy. I think that we should do what we can to ensure that
its hard to create templates that don't work if a non-obvious property is
set somewhere. We actually do have this (for example, VM namespaces allow
you to do some fancy and subtle things that would surely break if namespaces
(or 'local scope') was turned off....
Geir
>
> This is a tricky question because thinking it over again, we should be
> trying to enforce MVC, and if you give people the option....
>
> ..but then again they have J?P for that....
> :)
>
> Saimon
>
RE: floating point types
Posted by Saimon Moore <sm...@serikat.es>.
I tend to agree with not adding floating point processing! IMO, for web
application it's definetly anti-MVC because it encourages (unwittingly
perhaps in some cases) code like
#if ($Variables.Sales > $Variables.SalesTarget) something #end.
with does not belong in the view (and reminds me of a three letter scripting
language that begins with J and ends with P).
On the other hand since velocity these days is not only being used for web
apps (code generation etc..) and someone has gone ahead and written the
floating-point support, (and in the interest of satisfying both appetites),
why not introduce the code to velocity and add a property (flag) to
enable/disable floating point support in velocity.props.
This is a tricky question because thinking it over again, we should be
trying to enforce MVC, and if you give people the option....
..but then again they have J?P for that....
:)
Saimon
Re: floating point types
Posted by Jason van Zyl <jv...@apache.org>.
On 8/28/01 2:04 PM, "Lane Sharman" <la...@san.rr.com> wrote:
> Jason,
>
> Is there an immutable law that says velocity must be used exclusively to
> render
> a skin, a view? Your discussion and observations are predicated on this
> assumption, view :).
I never said anything of the sort. If you want floating point comparison
than use a context tool. That's what I said.
>
> -lane
>
> Jason van Zyl wrote:
>
>> On 8/31/01 8:09 PM, "Nathan Bubna" <na...@esha.com> wrote:
>>
>>>> or worse "you can use $Var.AnIntProperty in a if, because it's an integer,
>>>> but you can't use $blah.AnDoubleProperty because it's a float"
>>>
>>> i have to admit this point pushes me further toward the 'make velocity
>>> handle floats' side of the discussion. it is one thing for a designer to
>>> remember to use '1' and '1.0' differently, but it becomes much less obvious
>>> when $foo.value fetches an integer and $bar.value gets a double.
>>
>> Why should you ever make a designer even think about those issues as to
>> whether something is a float or integer, more to the point why would a
>> designer even remotely care to deal with:
>>
>> #set ($float = "3.14")
>>
>> of
>>
>> #if ($monkey == $spunky) your monky $funky #end
>>
>> I don't know what designers most people have dealt with but they do not care
>> to know what velocity #directives are. Most of the templates I use in
>> systems that are primarily design (www.flashcan.com) have almost no
>> directives in them.
>>
>> People want floating point values because they are performing programmatic
>> actions that, IMO, should not be done in a template. Programmers using VTL
>> want floating point processing. No designers I know (I admit I only know a
>> dozen or so) couldn't give a rat's ass what #wanker ($float) means. I will
>> always contend that there's something wrong with your app if you require any
>> sort of logical processing in your templates, if this is an MVC webapp we're
>> talking about. Often it is more convenient and expedient to have this
>> processing in templates, but this is certainly no boon to designers.
>>
>> If you're using velocity in some sort of code generation task than you may
>> very likely need some floating point comparison but this is being done by a
>> programmer so using a context tool in this case shouldn't be a problem.
>>
>> Velocity was never intended to be a scripting language. I am actually not
>> very keen on #set and #if/#else but I admit I use them because they are
>> convenient but I try not to use anything but macros, #foreach, and
>> $references. I am definitely against adding floating point processing.
>>
>> --
>>
>> jvz.
>>
>> Jason van Zyl
>>
>> http://tambora.zenplex.org
>> http://jakarta.apache.org/turbine
>> http://jakarta.apache.org/velocity
>> http://jakarta.apache.org/alexandria
>> http://jakarta.apache.org/commons
>
> --
> Lane Sharman
> http://corporate.acctiva.com/lane
>
>
>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
Re: floating point types
Posted by Lane Sharman <la...@san.rr.com>.
Jason,
Is there an immutable law that says velocity must be used exclusively to render
a skin, a view? Your discussion and observations are predicated on this
assumption, view :).
-lane
Jason van Zyl wrote:
> On 8/31/01 8:09 PM, "Nathan Bubna" <na...@esha.com> wrote:
>
> >> or worse "you can use $Var.AnIntProperty in a if, because it's an integer,
> >> but you can't use $blah.AnDoubleProperty because it's a float"
> >
> > i have to admit this point pushes me further toward the 'make velocity
> > handle floats' side of the discussion. it is one thing for a designer to
> > remember to use '1' and '1.0' differently, but it becomes much less obvious
> > when $foo.value fetches an integer and $bar.value gets a double.
>
> Why should you ever make a designer even think about those issues as to
> whether something is a float or integer, more to the point why would a
> designer even remotely care to deal with:
>
> #set ($float = "3.14")
>
> of
>
> #if ($monkey == $spunky) your monky $funky #end
>
> I don't know what designers most people have dealt with but they do not care
> to know what velocity #directives are. Most of the templates I use in
> systems that are primarily design (www.flashcan.com) have almost no
> directives in them.
>
> People want floating point values because they are performing programmatic
> actions that, IMO, should not be done in a template. Programmers using VTL
> want floating point processing. No designers I know (I admit I only know a
> dozen or so) couldn't give a rat's ass what #wanker ($float) means. I will
> always contend that there's something wrong with your app if you require any
> sort of logical processing in your templates, if this is an MVC webapp we're
> talking about. Often it is more convenient and expedient to have this
> processing in templates, but this is certainly no boon to designers.
>
> If you're using velocity in some sort of code generation task than you may
> very likely need some floating point comparison but this is being done by a
> programmer so using a context tool in this case shouldn't be a problem.
>
> Velocity was never intended to be a scripting language. I am actually not
> very keen on #set and #if/#else but I admit I use them because they are
> convenient but I try not to use anything but macros, #foreach, and
> $references. I am definitely against adding floating point processing.
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
--
Lane Sharman
http://corporate.acctiva.com/lane
Re: floating point types
Posted by Jason van Zyl <jv...@apache.org>.
On 8/31/01 8:09 PM, "Nathan Bubna" <na...@esha.com> wrote:
>> or worse "you can use $Var.AnIntProperty in a if, because it's an integer,
>> but you can't use $blah.AnDoubleProperty because it's a float"
>
> i have to admit this point pushes me further toward the 'make velocity
> handle floats' side of the discussion. it is one thing for a designer to
> remember to use '1' and '1.0' differently, but it becomes much less obvious
> when $foo.value fetches an integer and $bar.value gets a double.
Why should you ever make a designer even think about those issues as to
whether something is a float or integer, more to the point why would a
designer even remotely care to deal with:
#set ($float = "3.14")
of
#if ($monkey == $spunky) your monky $funky #end
I don't know what designers most people have dealt with but they do not care
to know what velocity #directives are. Most of the templates I use in
systems that are primarily design (www.flashcan.com) have almost no
directives in them.
People want floating point values because they are performing programmatic
actions that, IMO, should not be done in a template. Programmers using VTL
want floating point processing. No designers I know (I admit I only know a
dozen or so) couldn't give a rat's ass what #wanker ($float) means. I will
always contend that there's something wrong with your app if you require any
sort of logical processing in your templates, if this is an MVC webapp we're
talking about. Often it is more convenient and expedient to have this
processing in templates, but this is certainly no boon to designers.
If you're using velocity in some sort of code generation task than you may
very likely need some floating point comparison but this is being done by a
programmer so using a context tool in this case shouldn't be a problem.
Velocity was never intended to be a scripting language. I am actually not
very keen on #set and #if/#else but I admit I use them because they are
convenient but I try not to use anything but macros, #foreach, and
$references. I am definitely against adding floating point processing.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons