velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <revu...@wanadoo.es>
Subject Re: comparing monetary value
Date Thu, 17 Oct 2002 13:45:43 GMT
On Thursday 17 October 2002 11:16 am, Martin Jacobson wrote:
> Jonathan Revusky wrote:
> > On Wednesday 16 October 2002 09:44 am, you wrote:
> >>This thread, for all the heat it is generating, surely revolves around
> >>the separation between business logic, and presentation. If you think
> >>that a rigorous separation is a Good Thing, then there seems, on the
> >>present evidence, to be no requirement for Velocity to handle any
> >>numerical values other than integers.
> >
> > Excuse me. What evidence are you referring to?
>
> My own evidence, of course! :-)

<sigh>

Well, when you referred to "evidence", I thought you meant something besides 
your own subjective experience. It's certainly a very odd use of the term 
"evidence". You know, "evidence" typically means some objective thing that 
other people can look at. You know, like in those court-room dramas... the 
blood-stained murder weapon etcetera...

When you say "the evidence shows that..." and then, when challenged for what 
that evidence is, you say that the "evidence" in question is your own 
subjective experience, well... really... some people could even take this as 
a sign of intellectual dishonesty. It certainly seems tantamount to just 
saying: "It's that way because I say so!" 

> I enforce the separation between biz logic (servlet) & presentation (vm)
> rigorously, and have come across no requirement for any arithmetic
> features at all.

Hmm. Okay, but does it logically follow from there that nobody else has a need 
for any arithmetic features? Does it even follow logically from there that 
you yourself will never, in the future, have a need for such features?

You know, your statement is, AFAICS, almost completely meaningless. That you 
don't need a given feature that the tool lacks basically stands to reason, 
because, if you did, you presumably would have switched to using something 
else, but you haven't....

I mentioned elsewhere the classic statistic inference problem of 
"self-selection bias". That operates very strongly in this case. The people 
who are long-time users of a tool tend to think (disproportionately) that the 
tool in question is feature-complete because they don't need whatever missing 
feature. The people who differ mostly vote with their feet, but, as such, 
they are not around any more and become unobservable. This is "self-selection 
bias".

>
> >>If, on the other hand, you want to
> >>be able to manipulate, eg, monetary values in the template, then
> >>'vanilla' Velocity won't work for you.
> >>
> >>My preference is for rigorous separation - but I can think of
> >>circumstances where the 'quick hack' option of putting calculations, and
> >>numerical comparisons in the presentation layer might make sense. (But
> >>then, I'd use JSPs, to save myself learning Yet Another Programming
> >>Language!)
> >
> > Well, I have to strongly disagree with this. The reason I would not use
> > JSP's is because I think that working with embedded Java constructs is
> > not accessible to a non-programmer. I want a separate team to control
> > presentation with absolutely minimal involvement from myself.
>
> On further reflection, I also disagree with myself! The reason I went to
> Velocity in the first place was to escape from JSPs! However, there's
> more than one way to skin a cat, and extending the template engine to
> handle this kind of thing isn't neccessarily The Right Way

Maybe not, but it is a matter of legitimate technical debate. However, in a 
legitimate debate, you can't speak of "evidence" and have the "evidence" be 
your own subjective experience which is not observable by anybody else.

>
> Let's take the example you mentioned of calculating the lire equivalent
> of a Euro value: I agree that this is purely a presentation issue, but
> why do I have to do this calculation server-side? Web developers already
> use JavaScript for other purposes (eg, form data validation, fancy
> roll-overs and the like), so why not use that?

They could. However, that's introducing yet another scripting tool into the 
mix, which potentially complicates project management considerably. 

Also, a templating tool can be used for other things besides web applications. 
Is it reasonable to assume that a javascript engine operates on another pass 
after the template engine produces its output?

Suppose I'm generating a .ps or .rtf document? Or generating notificatoin 
emails? 

And besides, plenty of people have javascript turned off in their browsers 
(and certainly email clients) for security reasons. In general, I would say 
that it's an axiom of application development for the web that the fancier 
the client-side technology you use, the more you limit your potential 
audience. (And that's a trade-off of course...)


> To illustrate:
> <html>
> <head>
> 	<title>Testing embedded JavaScript</title>
> 	<script language="JavaScript">
> 		function showLire(euros)
> 		{
> 			document.write(euros * 1936);
> 		}
> 	</script>
> </head>
> <body>
> 	<p>1 Euro =
> 	<script language="JavaScript>
> 		showLire(1);
> 	</script>
> 	&nbsp;Lire
> 	</p>
> </body>
> </html>
>
> This puts the presentation logic in the presentation layer, where it
> belongs, using a presentation language that the designers already know,
> and doesn't waste server processor cycles on a problem that the client
> is perfectly capable of solving.

Martin, are you maintaining a visual image in your mind of what we are talking 
about? 

The specific case of converting a price in euros to lire: do you think that 
the server-side CPU cycles that this would expend are significant? Is this a 
reasonable point or are you just fishing around for any objection?

> Velocity's minimalism is its greatest strength, as it makes it easy for
> the Web designer to learn and use: let's keep it that way! (KISS)

Well, Martin, your proposed workaround for not having the decimal support in 
Velocity is that this should be handled in javascript and this implies that 
the template author necessarily masters javascript as well. You introduce 
another scripting language into the equation and then you invoke minimalism 
and KISS at the end.

Is this not a rather strange contradiction? You might think about that.

Regards,

Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html


--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>


Mime
View raw message