You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Will Glass-Husain <wg...@forio.com> on 2001/08/28 00:16:41 UTC
floating point types
Hi,
I'll throw my 2 cents in on this.
We've just finished a beta web application using Velocity to deliver
business training simulations. While we got amazing leverage from using
Velocity, one clear area for improvement is adding support for floating
point numbers. Earlier postings (which I just reviewed) covered many of the
issues here, but let me add a +1 (and examples) advocating an addition of
floating point support.
Specifically, we would like to use floating point numbers for the following
*presentation layer* tasks. The simpler tasks we'd expect web designers to
do. More complex tasks would probably be done by advanced users. None of
these users have access to the underlying Java code.
--> Set java bean properties that control presentation, e.g. the min & max
values of graphs
#set (Variables.MinValue = 20.0)
--> Control simulation characteristics (e.g. the timestep, a.k.a. the "dt"
calculation interval between steps).
#set ($ModelInfo.TimeStep = 0.5)
--> Show/hide text blocks depending on simulated results
#if ($Variables.Sales > 10000.0) Congratulations on your excellent score!
#else Work Harder! #end
What we've done as a stopgap for the last is create an integer method which
converts a string to an integer. But this notion of types (specifically the
difference between a integer, a double, and a string) is confusing to our
non-technical users. I think it's be better if Velocity just silently
handled doubles. (The syntax is below)
#if ($FunctionLibrary.integer($Variables.Sales) > 10000)
Congratulations on your excellent score! #else Work Harder! #end
Again, thanks for all the hard work on Velocity. I think it's clear that
this application framework rivals (or is superior too) many development
tools promoted by large established companies. (Yet the licensing structure
is very commercial developer friendly). As a small token of appreciation,
I've got a couple of small contributions of my own I'll submit once my
project is in production.
WILL
_______________________________________
Forio Business Simulations
Will Glass-Husain
(415) 440-7500 phone
(415) 235-4293 mobile
wglass@forio.com <ma...@forio.com>
www.forio.com <http://www.forio.com>
-----Original Message-----
From: gmj@mta7.srv.hcvlny.cv.net [mailto:gmj@mta7.srv.hcvlny.cv.net]On
Behalf Of Geir Magnusson Jr.
Sent: Monday, August 27, 2001 12:50 PM
To: velocity-user@jakarta.apache.org
Subject: Re: Any advancement on cross type if statements
Dave Cramer wrote:
>
> Currently it looks like velocity only accepts integers in an if
> statement which tests for numbers
>
> Has there been any advancement on fixing this?
There is one school of thought which holds that it isn't a problem to be
fixed. :)
>
> I hacked bob mcwirter's ispock to do the following
>
> if the types were the same then
> return rhs.equals(lhs)
>
> else
> return rhs.toString().equals(lhs.toString())
>
> Obviously there should be a little more error checking, but this works
> pretty well
>
> Thoughts?
How about just using a context tool?
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
Re: floating point types (The CSS twist)
Posted by Bojan Smojver <bo...@binarix.com>.
Jon Stevens wrote:
>
> on 8/28/01 11:10 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
>
> > Time to assign the Scarab guy to Tigris site... Just teasing... ;-)
> >
> > Bojan
>
> He is.
>
> The Tigris site was done before he was hired. The next revision of the
> Tigris site will use the unified CSS between Scarab and our core product
> which Tigris is an installation of.
>
> Needless to say, I still haven't been convinced of the need to add float's
> and the more I think about it and the more examples people give, the less
> inclined I am to give it a positive vote.
As far as I can tell, your main objections are along the lines of
increased complexity of Velocity, MVC screwups, type casting issues etc.
Typing problems come from the fact the Java is a strongly typed language
and float != int != long != double != short. Totally understandable and
I don't think anything like that should be introduced.
I think a few people hit it with suggestions that there shouldn't be
floats, doubles, ints, longs etc. but just numbers (along the lines of
other weakly typed languages like Javascript). That's where my (stupid)
BigDecimal suggestion was coming from.
The other approach would be even 'softer', kind of like a shell, where
any Velocity reference would be able to participate in arithmetic
operations. For instance:
----------------------------------------
#set ($a = "3.0")
#set ($b = "4.0")
#set ($c = $a / $b)
----------------------------------------
or:
----------------------------------------
#set ($a = "3")
#set ($b = "4.0")
#set ($c = $a / $b)
----------------------------------------
or:
----------------------------------------
#set ($a = 3)
#set ($b = 4.0)
#set ($c = $a / $b)
----------------------------------------
If you screw yourself up and write:
----------------------------------------
#set ($a = "not a number")
#set ($b = "4.0")
#set ($c = $a / $b)
----------------------------------------
or even more stupid:
----------------------------------------
#set ($a = $ref.getThatWrongHashtable())
#set ($b = "4.0")
#set ($c = $a / $b)
----------------------------------------
value of $c just becomes 'NaN' or something, and then even integers can
be dropped (I hope Geir doesn't live close to Sydney :-)
As I said before, I can live with or without it...
Bojan
Re: floating point types (The CSS twist)
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 11:10 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
> Time to assign the Scarab guy to Tigris site... Just teasing... ;-)
>
> Bojan
He is.
The Tigris site was done before he was hired. The next revision of the
Tigris site will use the unified CSS between Scarab and our core product
which Tigris is an installation of.
Needless to say, I still haven't been convinced of the need to add float's
and the more I think about it and the more examples people give, the less
inclined I am to give it a positive vote.
thanks,
-jon
Re: floating point types (The CSS twist)
Posted by Bojan Smojver <bo...@binarix.com>.
Jon Stevens wrote:
>
> on 8/28/01 10:26 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
>
> > And yet, it doesn't pass neither CSS nor HTML validation.
> >
> > http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fscarab.tigris.or
> > g%2Fbranding%2Fstyle.css&warning=1&profile=none
> >
> > http://validator.w3.org/check?uri=http%3A%2F%2Fscarab.tigris.org%2F&doctype=In
> > line
>
> Sigh. You are trying to validate the wrong file. That is the tigris.org
> site, not Scarab's (the applications CSS) file.
>
> I just validated Scarab's and it only has minor warnings.
>
> <http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
>
> -jon
Time to assign the Scarab guy to Tigris site... Just teasing... ;-)
Bojan
Re: floating point types (The CSS twist)
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 10:26 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
> And yet, it doesn't pass neither CSS nor HTML validation.
>
> http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fscarab.tigris.or
> g%2Fbranding%2Fstyle.css&warning=1&profile=none
>
> http://validator.w3.org/check?uri=http%3A%2F%2Fscarab.tigris.org%2F&doctype=In
> line
Sigh. You are trying to validate the wrong file. That is the tigris.org
site, not Scarab's (the applications CSS) file.
I just validated Scarab's and it only has minor warnings.
<http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
-jon
Re: floating point types (The CSS twist)
Posted by Bojan Smojver <bo...@binarix.com>.
And yet, it doesn't pass neither CSS nor HTML validation.
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fscarab.tigris.org%2Fbranding%2Fstyle.css&warning=1&profile=none
http://validator.w3.org/check?uri=http%3A%2F%2Fscarab.tigris.org%2F&doctype=Inline
Though who knows what would happen if the expert had floating point
numbers available... :-))
Bojan
Jon Stevens wrote:
>
> Nice try, but Scarab has a very advanced CSS stylesheet done by a CSS expert
> and it doesn't seem to need any of that.
>
> :-)
>
> -jon
>
> on 8/28/01 9:23 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
>
> > The CSS 1 and CSS 2 specifications talk about this:
> >
> > ----------------------------------------------------
> > <p style="font-size: 1.5em">This is important!</p>
> > ----------------------------------------------------
> >
> > What I'm getting at here is the fact that the floating point number is
> > being used to describe a purely presentation layer property. So, one can
> > expect from a web designer to do something like:
> >
> > ----------------------------------------------------
> > #set ($baseFontSize = 1.1)
> >
> > #set ($importantFactor = 1.5)
> > #set ($veryImportantFactor = 2.0)
> >
> > and then just use those numbers later:
> >
> > #set ($importantFontSize = $baseFontSize * $importantFactor)
> > #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> > ----------------------------------------------------
> >
> > and then in HTML:
> >
> > ----------------------------------------------------
> > <p style="font-size: ${importantFontSize}em">This is important!</p>
> > <p style="font-size: ${veryImportantFontSize}em">This is very
> > important!</p>
> > ----------------------------------------------------
> >
> > This can (obviously) be rewritten in many different ways, but one could
> > argue that floating point arithmetic is important for presentation
> > layer, since otherwise an engineer would have to write a multiplication
> > tool for something that doesn't belong into business logic at all.
> >
> > Personally, I've never had a need to use floating point numbers in
> > Velocity, so I won't miss it much if it isn't there. What would be the
> > rationale for not enabling the above?
> >
> > Bojan
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: floating point types (The CSS twist)
Posted by Jon Stevens <jo...@latchkey.com>.
Nice try, but Scarab has a very advanced CSS stylesheet done by a CSS expert
and it doesn't seem to need any of that.
:-)
-jon
on 8/28/01 9:23 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
> The CSS 1 and CSS 2 specifications talk about this:
>
> ----------------------------------------------------
> <p style="font-size: 1.5em">This is important!</p>
> ----------------------------------------------------
>
> What I'm getting at here is the fact that the floating point number is
> being used to describe a purely presentation layer property. So, one can
> expect from a web designer to do something like:
>
> ----------------------------------------------------
> #set ($baseFontSize = 1.1)
>
> #set ($importantFactor = 1.5)
> #set ($veryImportantFactor = 2.0)
>
> and then just use those numbers later:
>
> #set ($importantFontSize = $baseFontSize * $importantFactor)
> #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> ----------------------------------------------------
>
> and then in HTML:
>
> ----------------------------------------------------
> <p style="font-size: ${importantFontSize}em">This is important!</p>
> <p style="font-size: ${veryImportantFontSize}em">This is very
> important!</p>
> ----------------------------------------------------
>
> This can (obviously) be rewritten in many different ways, but one could
> argue that floating point arithmetic is important for presentation
> layer, since otherwise an engineer would have to write a multiplication
> tool for something that doesn't belong into business logic at all.
>
> Personally, I've never had a need to use floating point numbers in
> Velocity, so I won't miss it much if it isn't there. What would be the
> rationale for not enabling the above?
>
> Bojan
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: OT: css stuff (was Re: floating point types (The CSS twist))
Posted by Bojan Smojver <bo...@binarix.com>.
todd fahrner wrote:
>
> On Tuesday, August 28, 2001, at 09:23 , Bojan Smojver wrote:
>
> > The CSS 1 and CSS 2 specifications talk about this:
> >
> > ----------------------------------------------------
> > <p style="font-size: 1.5em">This is important!</p>
> > ----------------------------------------------------
> >
> > What I'm getting at here is the fact that the floating point number is
> > being used to describe a purely presentation layer property. So, one can
> > expect from a web designer to do something like:
> >
> > ----------------------------------------------------
> > #set ($baseFontSize = 1.1)
>
> that wouldn't be very smart as a value for a "base" font size in em units,
> at least not if applied to elements that might find themselves in a
> parent-child relationship, such as TD in the case of nested tables.
> Because the font-size value of the nested TD would then work out to 1.21x
> of the first TD. Which itself might be nested in a div or in body or
> whatever. Applied to font-size, em units are relative to the font size of
> the parent element, not, as commonly asserted, to the size selected by the
> user in UA prefs. It's a special case that 1em = the user-selected size.
>
> > #set ($importantFactor = 1.5)
> > #set ($veryImportantFactor = 2.0)
> >
> > and then just use those numbers later:
> >
> > #set ($importantFontSize = $baseFontSize * $importantFactor)
> > #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> > ----------------------------------------------------
> >
> > and then in HTML:
> >
> > ----------------------------------------------------
> > <p style="font-size: ${importantFontSize}em">This is important!</p>
> > <p style="font-size: ${veryImportantFontSize}em">This is very
> > important!</p>
>
> If you're going to embed the formatting inline like that, instead of in an
> external stylesheet, it would be less verbose and more portable just to
> use presentational HTML attrs/elements, like BIG, SMALL, FONT, etc, or,
> better yet, elements with semantics like EM or STRONG (for important and
> very important, respectively). You could use Velocity to do some
> non-redundant things in CSS per se, though, like symbolic constants. For
> instance, Scarab's stylesheet sets many background and foreground colors
> on various selections redundantly. These could become, e.g., $bgcolor_a,
> $color_a, $bgcolor_b, $color_b, etc., for easier maintenance. Not that
> manual maintenance of most CSS files is too hard.
>
> as for the warnings W3C's CSS Validator throws about Scarab's CSS, I paste
> part of a reply to Jon, who alerted me to this thread:
As I said, this can be done in many different ways, which is obvious.
Never claimed that it was good style, correct or anything like that. It
is presentation and it uses floating point numbers, that's all. This
could have been a CAD system that needed a zoom factor calculation,
which is presentation as well. Totally irrelevant.
> > 1. the "errors" below reflect the limitations of the QA software and the
> > highly debatable opinions of its designers. they are absolutely not
> > errors in any chapter-and-verse sense.
> >
>
> > <http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
> >
> > Line : 66 Level : 1 You have no color with your background-color : .docs
> > .toc
> >
> > The opinion reflected in this message is that you should never specify
> > background or foreground colors alone for any selected element, since
> > user or UA stylesheets might lead to contrast failures. For instance, you
> > shouldn't say that paragraph text should be black without also specifying
> > that paragraph backgrounds should be some color sufficiently lighter than
> > black. Nevermind that you are careful to set the parent elements of
> > paragraphs (like BODY) to have a suitably contrasting color - the QA
> > software author thinks you need to specify such things redundantly on
> > every single selected element! Why? because users or UAs might have
> > stylesheets that set paragraph text to white without specifying a
> > background color, and the merged result will be white on white. Phooey:
> > the 12 users in the world who use personal stylesheets know better, and
> > they will be careful to take care of all such dependencies. It is the
> > author-stylesheet designers' (our) responsibility to write lean,
> > accessible, maintainable, cool-looking sheets more than to defend
> > verbosely against such sloppy edge-case user-stylesheet authoring!
>
> --
> todd fahrner
Dunno what you talking about here, the failed stylesheets from Tigris
site produce this:
--------------------------------------------
Line: 8 Context : .Header
Property bottom-margin doesn't exist : 4px
Line: 9 Context : .ProjectNameHeader
Property bottom-margin doesn't exist : 4px
Line: 12 Context : .Download
Invalid number : color66666 is not a valid color 3 or 6 hexadecimals
numbers : #66666
Line: 24 Context : .NewsDateTable
Invalid number : colorParse Error - #
Line: 25 Context : .SiteHeader
Property bottom-margin doesn't exist : 4px
Line: 36 Context : .Warning
Property bottom-margin doesn't exist : 4px
--------------------------------------------
Mostly 'bottom-margin' (which doesn't exist in CSS) instead of
'margin-bottom'. But good for having fun... :-)
Bojan
OT: css stuff (was Re: floating point types (The CSS twist))
Posted by todd fahrner <tf...@collab.net>.
On Tuesday, August 28, 2001, at 09:23 , Bojan Smojver wrote:
> The CSS 1 and CSS 2 specifications talk about this:
>
> ----------------------------------------------------
> <p style="font-size: 1.5em">This is important!</p>
> ----------------------------------------------------
>
> What I'm getting at here is the fact that the floating point number is
> being used to describe a purely presentation layer property. So, one can
> expect from a web designer to do something like:
>
> ----------------------------------------------------
> #set ($baseFontSize = 1.1)
that wouldn't be very smart as a value for a "base" font size in em units,
at least not if applied to elements that might find themselves in a
parent-child relationship, such as TD in the case of nested tables.
Because the font-size value of the nested TD would then work out to 1.21x
of the first TD. Which itself might be nested in a div or in body or
whatever. Applied to font-size, em units are relative to the font size of
the parent element, not, as commonly asserted, to the size selected by the
user in UA prefs. It's a special case that 1em = the user-selected size.
> #set ($importantFactor = 1.5)
> #set ($veryImportantFactor = 2.0)
>
> and then just use those numbers later:
>
> #set ($importantFontSize = $baseFontSize * $importantFactor)
> #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> ----------------------------------------------------
>
> and then in HTML:
>
> ----------------------------------------------------
> <p style="font-size: ${importantFontSize}em">This is important!</p>
> <p style="font-size: ${veryImportantFontSize}em">This is very
> important!</p>
If you're going to embed the formatting inline like that, instead of in an
external stylesheet, it would be less verbose and more portable just to
use presentational HTML attrs/elements, like BIG, SMALL, FONT, etc, or,
better yet, elements with semantics like EM or STRONG (for important and
very important, respectively). You could use Velocity to do some
non-redundant things in CSS per se, though, like symbolic constants. For
instance, Scarab's stylesheet sets many background and foreground colors
on various selections redundantly. These could become, e.g., $bgcolor_a,
$color_a, $bgcolor_b, $color_b, etc., for easier maintenance. Not that
manual maintenance of most CSS files is too hard.
as for the warnings W3C's CSS Validator throws about Scarab's CSS, I paste
part of a reply to Jon, who alerted me to this thread:
> 1. the "errors" below reflect the limitations of the QA software and the
> highly debatable opinions of its designers. they are absolutely not
> errors in any chapter-and-verse sense.
>
> <http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
>
> Line : 66 Level : 1 You have no color with your background-color : .docs
> .toc
>
> The opinion reflected in this message is that you should never specify
> background or foreground colors alone for any selected element, since
> user or UA stylesheets might lead to contrast failures. For instance, you
> shouldn't say that paragraph text should be black without also specifying
> that paragraph backgrounds should be some color sufficiently lighter than
> black. Nevermind that you are careful to set the parent elements of
> paragraphs (like BODY) to have a suitably contrasting color - the QA
> software author thinks you need to specify such things redundantly on
> every single selected element! Why? because users or UAs might have
> stylesheets that set paragraph text to white without specifying a
> background color, and the merged result will be white on white. Phooey:
> the 12 users in the world who use personal stylesheets know better, and
> they will be careful to take care of all such dependencies. It is the
> author-stylesheet designers' (our) responsibility to write lean,
> accessible, maintainable, cool-looking sheets more than to defend
> verbosely against such sloppy edge-case user-stylesheet authoring!
--
todd fahrner
Re: floating point types (The CSS twist)
Posted by Bojan Smojver <bo...@binarix.com>.
The CSS 1 and CSS 2 specifications talk about this:
----------------------------------------------------
<p style="font-size: 1.5em">This is important!</p>
----------------------------------------------------
What I'm getting at here is the fact that the floating point number is
being used to describe a purely presentation layer property. So, one can
expect from a web designer to do something like:
----------------------------------------------------
#set ($baseFontSize = 1.1)
#set ($importantFactor = 1.5)
#set ($veryImportantFactor = 2.0)
and then just use those numbers later:
#set ($importantFontSize = $baseFontSize * $importantFactor)
#set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
----------------------------------------------------
and then in HTML:
----------------------------------------------------
<p style="font-size: ${importantFontSize}em">This is important!</p>
<p style="font-size: ${veryImportantFontSize}em">This is very
important!</p>
----------------------------------------------------
This can (obviously) be rewritten in many different ways, but one could
argue that floating point arithmetic is important for presentation
layer, since otherwise an engineer would have to write a multiplication
tool for something that doesn't belong into business logic at all.
Personally, I've never had a need to use floating point numbers in
Velocity, so I won't miss it much if it isn't there. What would be the
rationale for not enabling the above?
Bojan
Re: Yes, but what is business logic? (was: Business Logic in View
Posted by Nick Bauman <ni...@cortexity.com>.
>
>> Think about it: "if the user's score is this..." this is BUSINESS
>> LOGIC. You should never have this kind of code in your view.
>
> This is not necessarily business logic - where the boundary lies
> between business logic and the view depends on the application design.
> The requirements of an application's view may simply be "display the
> results to the user". The business logic doesn't care how that is done
> as long as the results are clear.
Your point, that business logic is a grey area, defies the definition
entirely. It's pretty clear: Business logic is logic applied to the model of
the application. :) Deciding what something should look like is clearly not
business logic. Webiste navigation decisions are clearly not business logic
either. Deciding whether a user's test score is valid or not... That is
CLEARLY business logic that belongs in the model of the application.
Writing applications that are not clear on what is and is not business logic
indicates poor design, not "grey area" definitions of what can and cannot be
business logic.
> If you get too pedantic about separation of view and content, you end
It's not pedantic. It's very clear.
> up with a situation where deciding whether a pixel on a monitor should
> be on or off becomes a "business logic" decision. Not all logic is
> business logic. Some logic is required to render the view.
You just proved my point with that last sentence.
> Rather than focusing on the example presented in the previous message,
> I believe the question is: Is the float data type so complex and
> incomprehensible to the designer that all manipulations of that data
> type should be the exclusive domain of the developer? I submit that it
> is not.
And I agree with you in principle, but that does not negate the value of not
having business logic in your view.
> A float is no more complex than, say, a string. It's a basic data type
> - there is no reason why designers shouldn't be able to inspect and use
> floats. There is no logic to a float - it is simply a data type.
> Please tell me where logic of any kind - much less the business logic
> that defines an application - comes into play here.
This isn't a semantic argument. I never said that floats have intrinsic
logic of their own. Don't misquote me.
> I believe there is no legitimate connection between the prohibition on
> floats and the separation of view and business logic. If anything,
Woah, nelly. To be perfectly clear: There is absolutely a legitimate
connection, but not in a direct way. The connection involves the use of
floats in the view that typically involves calculations that have nothing to
do with visualization or navigation.
The only halfway decent example for the use of fp's was in drawing a graph
on a page. And the complexity of that indicates that a context tool would be
a better use of ones time than to extend the Velocity language ;) Keeps the
page size down, too.
> forcing a designer to have knowledge of utility objects placed in the
> context in order to deal with a fundametal data type like a float
> threatens this view/logic separation more.
Disagree with you about the context tools. A context tool becomes the
"contract" between the designer and the engineer: the "C" in the MVC paradigm.
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
SMS: 6122327120@voicestream.net
Home: (612) 522-0165
Re: Yes, but what is business logic? (was: Business Logic in View a
bad thing (was floating point types))
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/28/01 4:06 AM, "Lloyd Llewellyn" <su...@twilight-systems.com>
wrote:
>
>> Think about it: "if the user's score is this..." this is BUSINESS LOGIC. You
>> should never have this kind of code in your view.
>
> This is not necessarily business logic - where the boundary lies between
> business logic and the view depends on the application design. The
> requirements of an application's view may simply be "display the results
> to the user". The business logic doesn't care how that is done as long
> as the results are clear.
>
> If you get too pedantic about separation of view and content, you end up
> with a situation where deciding whether a pixel on a monitor should be
> on or off becomes a "business logic" decision. Not all logic is
> business logic. Some logic is required to render the view.
I agree in principle, that it's hard for 'us' to say what is business logic
and what isn't, especially when Velocity isn't a niche tool, but more
general purpose.
> Rather than focusing on the example presented in the previous message, I
> believe the question is: Is the float data type so complex and
> incomprehensible to the designer that all manipulations of that data
> type should be the exclusive domain of the developer? I submit that it
> is not.
>
> A float is no more complex than, say, a string. It's a basic data type
> - there is no reason why designers shouldn't be able to inspect and use
> floats. There is no logic to a float - it is simply a data type. Please
> tell me where logic of any kind - much less the business logic that
> defines an application - comes into play here.
>
> I believe there is no legitimate connection between the prohibition on
> floats and the separation of view and business logic. If anything,
> forcing a designer to have knowledge of utility objects placed in the
> context in order to deal with a fundametal data type like a float
> threatens this view/logic separation more.
I think it is a bit extreme to deny any connection. I think that there is a
connection - what that connection is remains the question. This still comes
down to how substantial we believe the connection to be. One of our driving
philosophies has always been to keep it simple, clean, and support the MVC
contract. I think that recognizing that has served us very well and there
are quite a few examples of where we do diverge from that path for
convenience, for example the quiet reference, $!.
geir
Re: Yes, but what is business logic? (was: Business Logic in View
a bad thing (was floating point types))
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> Think about it: "if the user's score is this..." this is BUSINESS LOGIC. You
> should never have this kind of code in your view.
This is not necessarily business logic - where the boundary lies between
business logic and the view depends on the application design. The
requirements of an application's view may simply be "display the results
to the user". The business logic doesn't care how that is done as long
as the results are clear.
If you get too pedantic about separation of view and content, you end up
with a situation where deciding whether a pixel on a monitor should be
on or off becomes a "business logic" decision. Not all logic is
business logic. Some logic is required to render the view.
Rather than focusing on the example presented in the previous message, I
believe the question is: Is the float data type so complex and
incomprehensible to the designer that all manipulations of that data
type should be the exclusive domain of the developer? I submit that it
is not.
A float is no more complex than, say, a string. It's a basic data type
- there is no reason why designers shouldn't be able to inspect and use
floats. There is no logic to a float - it is simply a data type. Please
tell me where logic of any kind - much less the business logic that
defines an application - comes into play here.
I believe there is no legitimate connection between the prohibition on
floats and the separation of view and business logic. If anything,
forcing a designer to have knowledge of utility objects placed in the
context in order to deal with a fundametal data type like a float
threatens this view/logic separation more.
Re: Business Logic in View a bad thing (was floating point types)
Posted by Nick Bauman <ni...@cortexity.com>.
> Nick,
>
> I would remind you that there are other uses for Velocity than just
> MVC web design. For instance I use it to generate Java code to
> represent objects in our system that have special serialization code as
> well as the support objects to manage database persistance of those
> objects and collections of those objects. I also generate a web
> interface for manipulation of collections of these objects. In addition
> we are using velocity as a MVC tool to design the web server that these
> objects are used in.
>
> I know that most people are using velocity as a MVC web design tool
> but I know from experience that it is far more powerful than just that
> role.
I agree. And to concur even more strongly; as the first project I ever used
Velocity for had nothing to do with web development. The same held true in
that case. Don't forget MVC is from IBM's Smalltalk developers: it's 20+
years old! You can (and should) apply it wherever it makes sense.
The rest of your comment is basically a recapitulation of MVC best
practices. I think it's great!
> I have no real opinion as to the float issue. I can like Geir see
> it from both sides. One comment that I have is that if people are
> really worried about the impact of designers not understanding
> floats/doubles vs. ints do something like the following.
>
> #set( $account.balance = $Tools.num( "1210.11" ) )
> #set( $account.somevalue = $Tools.num( "100" ) )
>
> and have $Tools.num return a Double. You can then just have one set of
> comparison functions that compares doubles.
>
> What about displaying these values? Use a context tool to format them
> properly. With money you probably want to do this anyway as you are
> sure to have silly manager types that keep changing their minds about
> the layout of a number ( $1000 vs $1,000 vs $1000.00 vs $1,000.00 ).
>
> just my 2c.
>
> -Brian
:)
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
Home: (612) 522-0165
Re: Business Logic in View a bad thing (was floating point types)
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
Nick,
I would remind you that there are other uses for Velocity than just
MVC web design. For instance I use it to generate Java code to
represent objects in our system that have special serialization code as
well as the support objects to manage database persistance of those
objects and collections of those objects. I also generate a web
interface for manipulation of collections of these objects. In addition
we are using velocity as a MVC tool to design the web server that these
objects are used in.
I know that most people are using velocity as a MVC web design tool
but I know from experience that it is far more powerful than just that
role.
I have no real opinion as to the float issue. I can like Geir see
it from both sides. One comment that I have is that if people are
really worried about the impact of designers not understanding
floats/doubles vs. ints do something like the following.
#set( $account.balance = $Tools.num( "1210.11" ) )
#set( $account.somevalue = $Tools.num( "100" ) )
and have $Tools.num return a Double. You can then just have one set of
comparison functions that compares doubles.
What about displaying these values? Use a context tool to format them
properly. With money you probably want to do this anyway as you are
sure to have silly manager types that keep changing their minds about
the layout of a number ( $1000 vs $1,000 vs $1000.00 vs $1,000.00 ).
just my 2c.
-Brian
--- Nick Bauman <ni...@cortexity.com> wrote:
> Will,
>
> > --> Show/hide text blocks depending on simulated results
> > #if ($Variables.Sales > 10000.0) Congratulations on your excellent
> > score!
> > #else Work Harder! #end
>
> Think about it: "if the user's score is this..." this is BUSINESS
> LOGIC. You
> should never have this kind of code in your view.
>
> > #if ($FunctionLibrary.integer($Variables.Sales) > 10000)
> > Congratulations on your excellent score! #else Work Harder! #end
> >
>
> Ditto, you are making business decisions in your view. A good thing?
> No. So
> if your argument for floating point is so you can do "more powerful"
> things
> in your app, which includes spreading liberally your business
> decisions to
> the view, I reject that.
>
> Velocity give you just enough power to do the job, not too much so
> that you
> shoot yourslef in the foot, which is where
>
> "#if ($FunctionLibrary.integer($Variables.Sales) > 10000)
> Congratulations on your excellent score! #else Work Harder!"
>
> is headed.
>
> --
> Nick Bauman
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Business Logic in View a bad thing (was floating point types)
Posted by Nick Bauman <ni...@cortexity.com>.
Will,
> --> Show/hide text blocks depending on simulated results
> #if ($Variables.Sales > 10000.0) Congratulations on your excellent
> score!
> #else Work Harder! #end
Think about it: "if the user's score is this..." this is BUSINESS LOGIC. You
should never have this kind of code in your view.
> #if ($FunctionLibrary.integer($Variables.Sales) > 10000)
> Congratulations on your excellent score! #else Work Harder! #end
>
Ditto, you are making business decisions in your view. A good thing? No. So
if your argument for floating point is so you can do "more powerful" things
in your app, which includes spreading liberally your business decisions to
the view, I reject that.
Velocity give you just enough power to do the job, not too much so that you
shoot yourslef in the foot, which is where
"#if ($FunctionLibrary.integer($Variables.Sales) > 10000)
Congratulations on your excellent score! #else Work Harder!"
is headed.
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
Home: (612) 522-0165
Re: floating point types
Posted by "Henning P. Schmiedehausen" <ma...@hometree.net>.
Jon Stevens <jo...@latchkey.com> writes:
>> Velocity is good and cool and great as it currently is. But there is
>> still vast room for improvement. Especially in the region of
>> expressions. Why is there no "XOR" operator when I have "AND" and "OR" ?
>Yea, that's smart. Lets write a programming language. Not.
The remove loops and conditionals.
If you have these, you have a complete programming language. At least
that's what I learned in my CS courses.
You can easily do loops and conditionals in your business objects. Not.
I'm really happy with Geirs' approach to Velocity. He listens to
suggestions and tries to move at a leisure and good pace.
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
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 1:44 AM, "Henning P. Schmiedehausen" <ma...@hometree.net>
wrote:
> Come on Jon. They do Visual Basic all day long. They actually _can_ write
The designers I know don't know VB. They all use Mac's, not PC's.
> if ($a > 20.0) then ....
>
> If we impose arbitrary limits on the people we want to use Velocity
> instead of JSP and VB, then me might want to consider streamlining
> some of the abilities of Velocity.
>
> I consider Velocity the "glue" between my business objects which are
> written by developers and the design written by designers. It would be
> nice to see that the "glue" can actually connect plastic and metal
> equally good as metal and metal.
>
> Velocity is good and cool and great as it currently is. But there is
> still vast room for improvement. Especially in the region of
> expressions. Why is there no "XOR" operator when I have "AND" and "OR" ?
Yea, that's smart. Lets write a programming language. Not.
-jon
Re: floating point types
Posted by "Henning P. Schmiedehausen" <ma...@hometree.net>.
Jon Stevens <jo...@latchkey.com> writes:
>#if ($Variables.Sales.greaterThan("10000.0"))
>I actually think that the above is more readable to a web designer than ">".
Come on Jon. They do Visual Basic all day long. They actually _can_ write
if ($a > 20.0) then ....
If we impose arbitrary limits on the people we want to use Velocity
instead of JSP and VB, then me might want to consider streamlining
some of the abilities of Velocity.
I consider Velocity the "glue" between my business objects which are
written by developers and the design written by designers. It would be
nice to see that the "glue" can actually connect plastic and metal
equally good as metal and metal.
Velocity is good and cool and great as it currently is. But there is
still vast room for improvement. Especially in the region of
expressions. Why is there no "XOR" operator when I have "AND" and "OR" ?
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
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/27/01 3:16 PM, "Will Glass-Husain" <wg...@forio.com> wrote:
> Hi,
>
> I'll throw my 2 cents in on this.
>
> We've just finished a beta web application using Velocity to deliver
> business training simulations. While we got amazing leverage from using
> Velocity, one clear area for improvement is adding support for floating
> point numbers. Earlier postings (which I just reviewed) covered many of the
> issues here, but let me add a +1 (and examples) advocating an addition of
> floating point support.
>
> Specifically, we would like to use floating point numbers for the following
> *presentation layer* tasks. The simpler tasks we'd expect web designers to
> do. More complex tasks would probably be done by advanced users. None of
> these users have access to the underlying Java code.
>
> --> Set java bean properties that control presentation, e.g. the min & max
> values of graphs
> #set (Variables.MinValue = 20.0)
#set ($Variables.setMinValue("20.0"))
You can then internally cast to a float.
> --> Control simulation characteristics (e.g. the timestep, a.k.a. the "dt"
> calculation interval between steps).
> #set ($ModelInfo.TimeStep = 0.5)
See above.
> --> Show/hide text blocks depending on simulated results
> #if ($Variables.Sales > 10000.0) Congratulations on your excellent score!
> #else Work Harder! #end
#if ($Variables.Sales.greaterThan("10000.0"))
I actually think that the above is more readable to a web designer than ">".
> What we've done as a stopgap for the last is create an integer method which
> converts a string to an integer. But this notion of types (specifically the
> difference between a integer, a double, and a string) is confusing to our
> non-technical users. I think it's be better if Velocity just silently
> handled doubles. (The syntax is below)
>
> #if ($FunctionLibrary.integer($Variables.Sales) > 10000)
> Congratulations on your excellent score! #else Work Harder! #end
See above.
> Again, thanks for all the hard work on Velocity. I think it's clear that
> this application framework rivals (or is superior too) many development
> tools promoted by large established companies. (Yet the licensing structure
> is very commercial developer friendly). As a small token of appreciation,
> I've got a couple of small contributions of my own I'll submit once my
> project is in production.
Thanks!
-jon
Re: floating point types
Posted by Bojan Smojver <bo...@binarix.com>.
"Geir Magnusson Jr." wrote:
>
> On 8/27/01 7:01 PM, "Lloyd Llewellyn" <su...@twilight-systems.com>
> wrote:
>
> >
> >
> >> I do see both sides of this - I can see the need for it, however I can also
> >> see why we should keep it out if at all possible. Of course, this requires
> >> a devil's advocate... :)
> >
> > I still don't understand why a float data type is so despised by the
> > Velocity developers :-)
> >
> > It seems like a lot of unnecessary trouble for the developer to provide
> > a bunch of otherwise extraneous utility methods like
> > $myObject.isGreaterThan() called on strings instead of just letting the
> > template designer use ordinary, everyday, floating point numbers and
> > understandable symbols ">" . To me it feels like an inelegant
> > work-around for a problem that doesn't have to exist.
> >
> > I guess you can file that as a +1 for floats :-)
> >
>
> Like I said, I can see both sides. The fundamental argument will be along
> the lines of keeping velocity as clean and simple as possible, and limiting
> the data types is one aspect of that. And it's not a showstopper because
> you still do what you need to do. On the other hand, if you really need to
> work with floats, it's a pain. Any designers watch this list and have an
> opinion about floating point numbers?
>
> Geir
Just occurred to me (probably the stupidest suggestion you've ever
heard) that the numbers in Velocity can be handled through something
like BigDecimal type. The implementation would be one (instead of
Integer, the guts would be rewritten with BigDecimal) and would cater
for both the integral types and floating point types, without any
precision loss. It would hurt the performance though...
My 1 cent, since Aussie dollar is pretty weak these days :-)
Bojan
Re: floating point types
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> Yes, there are some very compelling reasons to put in floating point support
> - however, there are some very compelling reasons not to, and the balance
> between and affected community size are the things that I keep going
> mentally over and over...
Can you explain to me at a third grade level why not recognizing
non-integer numbers in VTL is good? I confess I still don't get it.
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/29/01 4:31 AM, "Bill Burton" <bi...@progress.com> wrote:
> Hello,
>
> "Geir Magnusson Jr." wrote:
>>
>> On 8/28/01 12:26 PM, "Bill Burton" <bi...@progress.com> wrote:
>>
>>> Hello,
>>>
>>> Something to consider ...
>>>
>>> Kirk Spadt wrote:
>>>>>>>>> 5. "The Velocity syntax will have to change"
>>>>
>>>> The Velocity language changes are limited to one item. The only
>>>> change I had to make to the parser was to add a FloatingLiteral to
>>>> the grammar and tree. Otherwise, the grammar is the same.
>>>
>>> If float support was to be added, should the parser be locale sensitive?
>>> Will template designers be forced to use "." as a decimal such as 10.5
>>> when entering 10,5 is customary for them? Is that okay?
>>
>> :)
>>
>> Didn't think of that, I will admit. Can you imagine the stew that would
>> create?
>
> Actually, it may not be too hard or messy to implement the parsing of
> locale specific decimals. The parser would have to retrieve the value of
> the decimal character dynamically instead of using a hard coded ".".
>
> After looking at the Java API docs, it appears you would use something
> like this to get the decimal separator:
> char dc = new
> java.text.DecimalFormatSymbols(<desired-locale>).getDecimalSeparator();
> You may want to save the result for each locale in a Hashtable so the
> lookup is only done once.
I was less worried about the programming of the parser than the mess you get
when templates are now locale specific. I guess you can get a similar
situation now with template encoding, but there is no way around that - if
you want to work in local character sets, that¹s the way to do it.
Futher, the encoding is really something that happens outside of the core
engine - the core doesn't care what the encoding is - it's only peripheral
things like the resource loaders that have minor involvement in that.
Geir
Re: floating point types
Posted by Bill Burton <bi...@progress.com>.
Hello,
"Geir Magnusson Jr." wrote:
>
> On 8/28/01 12:26 PM, "Bill Burton" <bi...@progress.com> wrote:
>
> > Hello,
> >
> > Something to consider ...
> >
> > Kirk Spadt wrote:
> >>>>>>> 5. "The Velocity syntax will have to change"
> >>
> >> The Velocity language changes are limited to one item. The only
> >> change I had to make to the parser was to add a FloatingLiteral to
> >> the grammar and tree. Otherwise, the grammar is the same.
> >
> > If float support was to be added, should the parser be locale sensitive?
> > Will template designers be forced to use "." as a decimal such as 10.5
> > when entering 10,5 is customary for them? Is that okay?
>
> :)
>
> Didn't think of that, I will admit. Can you imagine the stew that would
> create?
Actually, it may not be too hard or messy to implement the parsing of
locale specific decimals. The parser would have to retrieve the value of
the decimal character dynamically instead of using a hard coded ".".
After looking at the Java API docs, it appears you would use something
like this to get the decimal separator:
char dc = new
java.text.DecimalFormatSymbols(<desired-locale>).getDecimalSeparator();
You may want to save the result for each locale in a Hashtable so the
lookup is only done once.
I was hoping some folks who deal with content for countries where this is
an issue would speak up. Maybe it isn't a big deal not having locale
support because they use used to using a "." decimal in programming
languages, etc. However, since template writers tend to be less
technical, maybe this could be an issue for them.
> >
> > Will adding this functionality affect performance in a negative way?
>
> Prollie not, but there will be overhead for comparisons. That is one of my
> 'cons'.
>
> > Adding anything locale sensitive to Velocity has other implications.
> > * Resource loaders may need a way to specify the locale via a property.
> > * A new version of the mergeTemplate method may need to be added so you
> > can specify the locale.
> > * A #locale directive may be a requirement so you can force a template to
> > be processed correctly.
If locale support was a requirement, the above would probably be the
primary issues in adding float support over the parsing since you then
need to be flexible in how the locale can be specified. Since Velocity
does not provide its own number and date formatting, it's currently locale
neutral which keeps it simple. It seems to me overkill add locale support
just so decimals can be parsed correctly.
> :/
>
> Geir
-Bill
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/28/01 12:26 PM, "Bill Burton" <bi...@progress.com> wrote:
> Hello,
>
> Something to consider ...
>
> Kirk Spadt wrote:
>>>>>>> 5. "The Velocity syntax will have to change"
>>
>> The Velocity language changes are limited to one item. The only
>> change I had to make to the parser was to add a FloatingLiteral to
>> the grammar and tree. Otherwise, the grammar is the same.
>
> If float support was to be added, should the parser be locale sensitive?
> Will template designers be forced to use "." as a decimal such as 10.5
> when entering 10,5 is customary for them? Is that okay?
:)
Didn't think of that, I will admit. Can you imagine the stew that would
create?
>
> Will adding this functionality affect performance in a negative way?
Prollie not, but there will be overhead for comparisons. That is one of my
'cons'.
> Adding anything locale sensitive to Velocity has other implications.
> * Resource loaders may need a way to specify the locale via a property.
> * A new version of the mergeTemplate method may need to be added so you
> can specify the locale.
> * A #locale directive may be a requirement so you can force a template to
> be processed correctly.
:/
Geir
>
> -Bill
Re: floating point types
Posted by Bill Burton <bi...@progress.com>.
Hello,
Something to consider ...
Kirk Spadt wrote:
> >>>>>5. "The Velocity syntax will have to change"
>
> The Velocity language changes are limited to one item. The only
> change I had to make to the parser was to add a FloatingLiteral to
> the grammar and tree. Otherwise, the grammar is the same.
If float support was to be added, should the parser be locale sensitive?
Will template designers be forced to use "." as a decimal such as 10.5
when entering 10,5 is customary for them? Is that okay?
Will adding this functionality affect performance in a negative way?
Adding anything locale sensitive to Velocity has other implications.
* Resource loaders may need a way to specify the locale via a property.
* A new version of the mergeTemplate method may need to be added so you
can specify the locale.
* A #locale directive may be a requirement so you can force a template to
be processed correctly.
-Bill
RE: floating point types
Posted by ps...@comcen.com.au.
Way to go Kirk!
Quoting Kirk Spadt <ki...@spadt.com>:
>
>
[ cut]
>
RE: floating point types
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> In trying to understand the resistance to adding floating point, I
> looked over the interchange on the group. Here are some thoughts:
Thank you for stating succinctly what I have only partially been able to
convey by picking on random points here and there, to little effect :-)
RE: floating point types
Posted by Kirk Spadt <ki...@spadt.com>.
My vote:
+1 for floating point in Velocity.
I will be releasing a patch for full floating point support for
Velocity for Geir to review within the next week. All coding is
complete, and the current test harness passes. I am currently
adding exhaustive TestCases to the test harness. This should be
complete within a week (working on it at night).
Keeping floating point support out of Velocity leaves a missing
piece in the implementation. Without floating point, only some
numbers are acceptable. Why not have the current math and
comparison operations available for all numbers?
In trying to understand the resistance to adding floating point, I
looked over the interchange on the group. Here are some thoughts:
>>>> 1. "Complexity"
It is more complex to explain to a page designer that a number that
might have a decimal point must be treated differently:
For integers:
#if($totalAmount < $amountForFreeFreight)
#include("freightChoice.vm")
#end
(nice and simple)
For floating point:
#if($FunctionLibrary.integer($totalAmount) <
$FunctionLibrary.integer($amountForFreeFreight) )
#include("freightChoice.vm")
#end
(harder to remember, document, understand, and get working, and
forces
the developer and page designer to agree on another api.)
>>>> 2. "Too much like programming"
Velocity already has this kind of programming: it includes
essential rudimentary arithmetic and comparisons, just enough to
give the page designer the tools to control the view (and keep page
layout out of the controller).
Adding floating point support simply fills the expectation that
numbers are supported, rather than only certain kinds of numbers.
>>>> 3. "Keep the syntax simple"
Adding floating point support adds more consistency to the language.
Being able to say: "We handle strings and numbers" is simpler than:
"We handle Strings and integers, but not bytes, shorts, longs,
floats, or doubles".
>>>> 4. "Limit the number of data types to keep it simple"
With this proposed implementation, upcasting of primitive data types
for assignment and comparison is automatically performed per Java
rules, and (optionally) downcasting is performed as required, after
range-checking and truncation testing. This minimizes the need for
the page designer to know the data types of the numeric values.
It is permissible to #set($double = 4) and to use #if($double >
$int). For the scientists, of course #set($double = 6.024e23) would
work as well. Because Velocity's function is to create the View,
only +, -, *, /, %, ==, !=, <, <=, >, and >= are supported.
Anything beyond that really belongs in the model.
>>>>>5. "The Velocity syntax will have to change"
The Velocity language changes are limited to one item. The only
change I had to make to the parser was to add a FloatingLiteral to
the grammar and tree. Otherwise, the grammar is the same.
I am hoping that having the implementation (almost) ready to go will
add some weight to support the addition of floating point.
Best regards,
-Kirk
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Kirk Spadt kirk@spadt.com
Keyware Systems, Inc. 610.964.9530
East coast Velocity Evangelist
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/27/01 10:53 PM, "Patrick E. Whitesell" <pw...@clickability.com>
wrote:
> Jon Stevens wrote:
>
>> Since we have released Velocity 1.0 (and even in the alpha/beta stage before
>> that), not a single change has gone into the Velocity Template Language
>> itself. 1.0b1 was back in March and here we are ~5 months later. I think
>> that speaks volumes on its own.
>>
>> Do not take any Velocity developers hesitation for additions as negative. We
>> are just overly cautious. That is a good thing.
>>
>> -jon
>>
>
> There was ALMOST a change in the VTL a few months ago (adding a 'null'
> token for use in method calls and whatnot), but it somehow got lost in
> the shuffle of the singleton/instance blitz. But I think that was by
> far the closest the dev team has come to even thinking about voting on a
> VTL change. Compare that to how often most in-house templating
> languages change and you'll realize how well thought out and powerful
> the VTL already is... Context tools can handle almost any perceived
> deficiency, and after a while you can even get used to the whitespace
> handling! :)
>
The bit about the context tools is an important point. I personally like
the idea of floating point handling in Velocity, but don't want to see it
there for a few reasons. What makes me comfortable with that position is
that indeed, context tools can handle it, and in a normal language that we
all work in, namely Java and further, those tools are very, very simple,
making no demands on the programmer to support some proprietary API, such as
taglibs. That isn't intended to be an attack on taglibs, but rather
illustrate how Velocity is very accommodating to whatever you want to do
with it.
Yes, there are some very compelling reasons to put in floating point support
- however, there are some very compelling reasons not to, and the balance
between and affected community size are the things that I keep going
mentally over and over...
Geir
(and I think we will revisit the NULL in 1.3)
Re: floating point types
Posted by "Patrick E. Whitesell" <pw...@clickability.com>.
Jon Stevens wrote:
>Since we have released Velocity 1.0 (and even in the alpha/beta stage before
>that), not a single change has gone into the Velocity Template Language
>itself. 1.0b1 was back in March and here we are ~5 months later. I think
>that speaks volumes on its own.
>
>Do not take any Velocity developers hesitation for additions as negative. We
>are just overly cautious. That is a good thing.
>
>-jon
>
There was ALMOST a change in the VTL a few months ago (adding a 'null'
token for use in method calls and whatnot), but it somehow got lost in
the shuffle of the singleton/instance blitz. But I think that was by
far the closest the dev team has come to even thinking about voting on a
VTL change. Compare that to how often most in-house templating
languages change and you'll realize how well thought out and powerful
the VTL already is... Context tools can handle almost any perceived
deficiency, and after a while you can even get used to the whitespace
handling! :)
--
Patrick E. Whitesell
pwhitesell@clickability.com
***************************************
This e-mail message may contain confidential and/or legally privileged information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this e-mail message is strictly prohibited.If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. DO NOT FORWARD THIS E-MAIL MESSAGE WITHOUT THE PERMISSION OF THE SENDER.
Re: floating point types
Posted by Jon Stevens <jo...@latchkey.com>.
Since we have released Velocity 1.0 (and even in the alpha/beta stage before
that), not a single change has gone into the Velocity Template Language
itself. 1.0b1 was back in March and here we are ~5 months later. I think
that speaks volumes on its own.
Do not take any Velocity developers hesitation for additions as negative. We
are just overly cautious. That is a good thing.
-jon
Re: floating point types
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> Like I said, I can see both sides. The fundamental argument will be along
> the lines of keeping velocity as clean and simple as possible, and limiting
> the data types is one aspect of that.
It keeps the "philosophical" design of Velocity clean, but it really
impacts negatively funcionality by making it counter-inuitive for
designers, and more labor-intensive for developers.
I'm all for clean and simple, but I do believe that this makes it less
clean and simple to use.
> Any designers watch this list and have an
> opinion about floating point numbers?
I can pass along the opinion of our designer second-hand. After I
explained to him the current VTL philosophy that handling of non-integer
numbers does not belong in the presentation layer, he kind of looked at
me like I was growing antlers and said:
"Uh... OK, I guess. Whatever."
:-)
ps - I hope this is not coming off as overly critical - I do have a
strong opinion on this one particular issue, but otherwise I wouldn't be
surprised if I never write another JSP page again. It's Velocity all
the way.
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/27/01 7:01 PM, "Lloyd Llewellyn" <su...@twilight-systems.com>
wrote:
>
>
>> I do see both sides of this - I can see the need for it, however I can also
>> see why we should keep it out if at all possible. Of course, this requires
>> a devil's advocate... :)
>
> I still don't understand why a float data type is so despised by the
> Velocity developers :-)
>
> It seems like a lot of unnecessary trouble for the developer to provide
> a bunch of otherwise extraneous utility methods like
> $myObject.isGreaterThan() called on strings instead of just letting the
> template designer use ordinary, everyday, floating point numbers and
> understandable symbols ">" . To me it feels like an inelegant
> work-around for a problem that doesn't have to exist.
>
> I guess you can file that as a +1 for floats :-)
>
Like I said, I can see both sides. The fundamental argument will be along
the lines of keeping velocity as clean and simple as possible, and limiting
the data types is one aspect of that. And it's not a showstopper because
you still do what you need to do. On the other hand, if you really need to
work with floats, it's a pain. Any designers watch this list and have an
opinion about floating point numbers?
Geir
Re: floating point types
Posted by Lloyd Llewellyn <su...@twilight-systems.com>.
> I do see both sides of this - I can see the need for it, however I can also
> see why we should keep it out if at all possible. Of course, this requires
> a devil's advocate... :)
I still don't understand why a float data type is so despised by the
Velocity developers :-)
It seems like a lot of unnecessary trouble for the developer to provide
a bunch of otherwise extraneous utility methods like
$myObject.isGreaterThan() called on strings instead of just letting the
template designer use ordinary, everyday, floating point numbers and
understandable symbols ">" . To me it feels like an inelegant
work-around for a problem that doesn't have to exist.
I guess you can file that as a +1 for floats :-)
Re: floating point types
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 2:05 AM, "Henning P. Schmiedehausen" <ma...@hometree.net>
wrote:
> Think about small, easy to write, urgently needed applications with
> less than 1000 lines of code in two or three files. This is currently
> the undisputed domain of perl and php just because it is easy to write
> a "single file contains it all, run as a cgi and forget about it"
> application.
I know that is not the market I care to be in with Velocity.
I admit that those tools indeed win in that category. They can have it.
> To me, the starting overhead (you need a class and a
> template and some helper tools and a this and a that) that doesn't
> matter if you write a 100,000 lines application but is heavy if you're
> under "you have two hours to whip it up" pressure.
Not true. Turbine provides you with the ability to create templates without
needing any objects in the context. It gives you a few default ones that
allow you to create what equate to mostly static pages or pages that do
things based on GET/POST data. If you want more, then you certainly need to
start adding stuff into the context.
> I don't use constants and #defines in applications that fit on a few
> screens full of code. All of the numbers are a) obvious and b) used
> only once. ;-)
Good for you.
:-)
-jon
Re: floating point types
Posted by "Henning P. Schmiedehausen" <ma...@hometree.net>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
>> --> Show/hide text blocks depending on simulated results
>> #if ($Variables.Sales > 10000.0) Congratulations on your excellent score!
>> #else Work Harder! #end
>Again, having that raw magic number scares me - for the same reasons we use
>constants in Java and #defines in C. When something that is a parameter
>like that shouldn't be in the template. Of course, it really isn't our
>place to tell you that, and you would have them anyway with tools or
>overridden methods.
Think about small, easy to write, urgently needed applications with
less than 1000 lines of code in two or three files. This is currently
the undisputed domain of perl and php just because it is easy to write
a "single file contains it all, run as a cgi and forget about it"
application. To me, the starting overhead (you need a class and a
template and some helper tools and a this and a that) that doesn't
matter if you write a 100,000 lines application but is heavy if you're
under "you have two hours to whip it up" pressure.
I don't use constants and #defines in applications that fit on a few
screens full of code. All of the numbers are a) obvious and b) used
only once. ;-)
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
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
Re: floating point types
Posted by Nathan Bubna <na...@esha.com>.
> 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 Will Glass-Husain <wg...@forio.com>.
Geir:
> I mean, if they can't tell the difference, then they will have a problem
> distinguishing between
> $foo.bar("10") And
> $foo.bar( 10 )
As a clarification, a number vs a string is probably ok. (Don't want to get
backed into a corner here) But you never know. (probably most yes but
others no).
Main point: The distinction between integers vs floats is subtle. It's hard
to tell designers "yes, '#if ($blah > 1)' works but '#if ($blah > 1.5)'
doesn't."
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".
WILL
-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
Sent: Monday, August 27, 2001 4:49 PM
To: velocity-user@jakarta.apache.org
Subject: Re: floating point types
On 8/27/01 7:41 PM, "Will Glass-Husain" <wg...@forio.com> wrote:
> Hi,
>
> Thanks for the workaround suggestions, namely:
>
>> #set( $Variables.MinValue = $num.float( "20.0" ) )
>> #set ($Variables.setMinValue("20.0"))
>
> I will probably implement this in the short term. But let me reiterate my
> main point: my template designers will not know the difference betweeen a
> float, integer, and string! They will see no difference between setting
an
> integer property
>
> #set ($ModelInfo.InitialSteps = 3) (expects an integer-- works)
> and
> #set ($ModelInfo.GraphMaxValue = 20.0) (expects a float -- doesn't
> work)
So are you suggesting that the real solution, if we are going to tailor this
for simplicity for designers, is to eliminate integers and just only have
strings?
I mean, if they can't tell the difference, then they will have a problem
distinguishing between
$foo.bar("10")
And
$foo.bar( 10 )
Right?
(Before anyone blows a valve, no, I wouldn't be interested in getting rid of
integers... )
>
> Any workaround (even setting to a string) is unintuitive, because again it
> is *different* than integers. If I do this for one float property, I have
> to do this for all my integer properties. It'd be nice if this worked
> similar to JavaScript, where all types were supported in an invisible way.
Except we have a very tight binding to Java objects.
>> Again, having that raw magic number scares me - for the same reasons we
> use
>> constants in Java and #defines in C. When something that is a parameter
>> like that shouldn't be in the template. Of course, it really isn't our
>> place to tell you that, and you would have them anyway with tools or
>> overridden methods.
>
> The problem is still here if I use velocity object for the ifs.
> #if ($Variables.Sales > $Variables.SalesTarget) something #end.
Indeed
> (I could use Jon's suggestion of a "greaterThan" method, but I find the
">"
> to be personally more intuitive).
I do too.
> As a final explanatory note:
>> I guess one question is why are these things *designers* have to decide,
>> rather than somewhere else in the app, which are then accessed like any
>> other reference in the context?
>
> As I noted in my last email, there are two needs here, both presentation
> oriented.
>
> (1) Configure dynamically generated information, like the height, width,
and
> axis of generated graphs. These decisions are often made by a designer not
> the programmer. We could put them elsewhere in the app, but then they
would
> just have to change two things instead of one.
>
> (2) Dynamically choose what HTML to present using IF statements. Again, I
> could code an elaborate architecture for this. But it would be nice to
> allow template designers to quickly put simple choices in without
> programming.
>
> Appreciate your attention to this email. I offer it as feedback on a
great
> product, and am happy to answer other questions if it is helpful.
If you pay attention to these lists, as can discuss any subject endlessly :)
Geir
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/27/01 7:41 PM, "Will Glass-Husain" <wg...@forio.com> wrote:
> Hi,
>
> Thanks for the workaround suggestions, namely:
>
>> #set( $Variables.MinValue = $num.float( "20.0" ) )
>> #set ($Variables.setMinValue("20.0"))
>
> I will probably implement this in the short term. But let me reiterate my
> main point: my template designers will not know the difference betweeen a
> float, integer, and string! They will see no difference between setting an
> integer property
>
> #set ($ModelInfo.InitialSteps = 3) (expects an integer-- works)
> and
> #set ($ModelInfo.GraphMaxValue = 20.0) (expects a float -- doesn't
> work)
So are you suggesting that the real solution, if we are going to tailor this
for simplicity for designers, is to eliminate integers and just only have
strings?
I mean, if they can't tell the difference, then they will have a problem
distinguishing between
$foo.bar("10")
And
$foo.bar( 10 )
Right?
(Before anyone blows a valve, no, I wouldn't be interested in getting rid of
integers... )
>
> Any workaround (even setting to a string) is unintuitive, because again it
> is *different* than integers. If I do this for one float property, I have
> to do this for all my integer properties. It'd be nice if this worked
> similar to JavaScript, where all types were supported in an invisible way.
Except we have a very tight binding to Java objects.
>> Again, having that raw magic number scares me - for the same reasons we
> use
>> constants in Java and #defines in C. When something that is a parameter
>> like that shouldn't be in the template. Of course, it really isn't our
>> place to tell you that, and you would have them anyway with tools or
>> overridden methods.
>
> The problem is still here if I use velocity object for the ifs.
> #if ($Variables.Sales > $Variables.SalesTarget) something #end.
Indeed
> (I could use Jon's suggestion of a "greaterThan" method, but I find the ">"
> to be personally more intuitive).
I do too.
> As a final explanatory note:
>> I guess one question is why are these things *designers* have to decide,
>> rather than somewhere else in the app, which are then accessed like any
>> other reference in the context?
>
> As I noted in my last email, there are two needs here, both presentation
> oriented.
>
> (1) Configure dynamically generated information, like the height, width, and
> axis of generated graphs. These decisions are often made by a designer not
> the programmer. We could put them elsewhere in the app, but then they would
> just have to change two things instead of one.
>
> (2) Dynamically choose what HTML to present using IF statements. Again, I
> could code an elaborate architecture for this. But it would be nice to
> allow template designers to quickly put simple choices in without
> programming.
>
> Appreciate your attention to this email. I offer it as feedback on a great
> product, and am happy to answer other questions if it is helpful.
If you pay attention to these lists, as can discuss any subject endlessly :)
Geir
RE: floating point types
Posted by Will Glass-Husain <wg...@forio.com>.
Hi,
Thanks for the workaround suggestions, namely:
> #set( $Variables.MinValue = $num.float( "20.0" ) )
> #set ($Variables.setMinValue("20.0"))
I will probably implement this in the short term. But let me reiterate my
main point: my template designers will not know the difference betweeen a
float, integer, and string! They will see no difference between setting an
integer property
#set ($ModelInfo.InitialSteps = 3) (expects an integer-- works)
and
#set ($ModelInfo.GraphMaxValue = 20.0) (expects a float -- doesn't
work)
Any workaround (even setting to a string) is unintuitive, because again it
is *different* than integers. If I do this for one float property, I have
to do this for all my integer properties. It'd be nice if this worked
similar to JavaScript, where all types were supported in an invisible way.
> Again, having that raw magic number scares me - for the same reasons we
use
> constants in Java and #defines in C. When something that is a parameter
> like that shouldn't be in the template. Of course, it really isn't our
> place to tell you that, and you would have them anyway with tools or
> overridden methods.
The problem is still here if I use velocity object for the ifs.
#if ($Variables.Sales > $Variables.SalesTarget) something #end.
(I could use Jon's suggestion of a "greaterThan" method, but I find the ">"
to be personally more intuitive).
As a final explanatory note:
> I guess one question is why are these things *designers* have to decide,
> rather than somewhere else in the app, which are then accessed like any
> other reference in the context?
As I noted in my last email, there are two needs here, both presentation
oriented.
(1) Configure dynamically generated information, like the height, width, and
axis of generated graphs. These decisions are often made by a designer not
the programmer. We could put them elsewhere in the app, but then they would
just have to change two things instead of one.
(2) Dynamically choose what HTML to present using IF statements. Again, I
could code an elaborate architecture for this. But it would be nice to
allow template designers to quickly put simple choices in without
programming.
Appreciate your attention to this email. I offer it as feedback on a great
product, and am happy to answer other questions if it is helpful.
Will
Re: floating point types
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 8/27/01 6:16 PM, "Will Glass-Husain" <wg...@forio.com> wrote:
> Hi,
>
> I'll throw my 2 cents in on this.
>
> We've just finished a beta web application using Velocity to deliver
> business training simulations. While we got amazing leverage from using
> Velocity, one clear area for improvement is adding support for floating
> point numbers. Earlier postings (which I just reviewed) covered many of the
> issues here, but let me add a +1 (and examples) advocating an addition of
> floating point support.
>
> Specifically, we would like to use floating point numbers for the following
> *presentation layer* tasks. The simpler tasks we'd expect web designers to
> do. More complex tasks would probably be done by advanced users. None of
> these users have access to the underlying Java code.
That indeed will be where the argument will have to be made...
I do see both sides of this - I can see the need for it, however I can also
see why we should keep it out if at all possible. Of course, this requires
a devil's advocate... :)
>
> --> Set java bean properties that control presentation, e.g. the min & max
> values of graphs
> #set (Variables.MinValue = 20.0)
>
> --> Control simulation characteristics (e.g. the timestep, a.k.a. the "dt"
> calculation interval between steps).
> #set ($ModelInfo.TimeStep = 0.5)
>
I guess one question is why are these things *designers* have to decide,
rather than somewhere else in the app, which are then accessed like any
other reference in the context?
For example
#set(Variables.MinValue = $user_minval)
Or something
Or, how about a small tool so you don't have to modify code that you don't
want to, or that isn't yours :
#set( $Variables.MinValue = $num.float( "20.0" ) )
Of course, this won't solve the confusion problem. I empathize and
understand the problem, but am not sure this won't bring more problems than
it solves.
> --> Show/hide text blocks depending on simulated results
> #if ($Variables.Sales > 10000.0) Congratulations on your excellent score!
> #else Work Harder! #end
Again, having that raw magic number scares me - for the same reasons we use
constants in Java and #defines in C. When something that is a parameter
like that shouldn't be in the template. Of course, it really isn't our
place to tell you that, and you would have them anyway with tools or
overridden methods.
> What we've done as a stopgap for the last is create an integer method which
> converts a string to an integer. But this notion of types (specifically the
> difference between a integer, a double, and a string) is confusing to our
> non-technical users. I think it's be better if Velocity just silently
> handled doubles. (The syntax is below)
>
> #if ($FunctionLibrary.integer($Variables.Sales) > 10000)
> Congratulations on your excellent score! #else Work Harder! #end
>
> Again, thanks for all the hard work on Velocity. I think it's clear that
> this application framework rivals (or is superior too) many development
> tools promoted by large established companies. (Yet the licensing structure
> is very commercial developer friendly). As a small token of appreciation,
> I've got a couple of small contributions of my own I'll submit once my
> project is in production.
That'll be great.
Geir
> WILL
>
> _______________________________________
> Forio Business Simulations
> Will Glass-Husain
> (415) 440-7500 phone
> (415) 235-4293 mobile
>
> wglass@forio.com <ma...@forio.com>
> www.forio.com <http://www.forio.com>
>
>
>
>
> -----Original Message-----
> From: gmj@mta7.srv.hcvlny.cv.net [mailto:gmj@mta7.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
> Sent: Monday, August 27, 2001 12:50 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: Any advancement on cross type if statements
>
>
> Dave Cramer wrote:
>>
>> Currently it looks like velocity only accepts integers in an if
>> statement which tests for numbers
>>
>> Has there been any advancement on fixing this?
>
> There is one school of thought which holds that it isn't a problem to be
> fixed. :)
>
>>
>> I hacked bob mcwirter's ispock to do the following
>>
>> if the types were the same then
>> return rhs.equals(lhs)
>>
>> else
>> return rhs.toString().equals(lhs.toString())
>>
>> Obviously there should be a little more error checking, but this works
>> pretty well
>>
>> Thoughts?
>
> How about just using a context tool?
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> Well done is better than well said - New England Proverb
>