Hi Nathan,
Makes sense to me. Case 1-3 are the way things work now. Since case #4
currently gives an error in the logs (not true or false) I see this as
backwards compatible.
WILL
----- Original Message -----
From: "Nathan Bubna" <[EMAIL PROTECTED]>
To: "Velocity Users List" <velocity-user@jakarta.apache.org>
Sent: Saturday, September 17, 2005 9:59 PM
Subject: Re: Comparing strings
i think the fact that it wasn't valid VTL for most cases helps, but i
believe we'll have to carefully decide on a good order of comparison
to pull this off for 1.5.
here's a barely thought out proposal for doing #if( $foo == $bar ):
1. if foo and bar are both numbers, do a numeric comparison.
2. if foo and bar are strings, do a direct string comparison
3. if bar is an instance of foo's class and/or foo is an instance of
bar's class, then do foo.equals(bar)
4. otherwise, compare foo.toString() with bar.toString()
the key here for backwards compatibility is the *and* part of #3.
equal classes will have to be compared using foo.equals(bar), as that
has always been valid VTL. i'm not as sure about the *or* part of #3,
as i can't recall or test at the moment (i'm in a hurry) whether it is
valid to do #if( $a == $b ) when $b is a subclass of $a (or vice
versa). i'm also not sure which the developer/designer is more likely
to expect in that case: a string comparison or a java equals()
comparison. thoughts?
On 9/16/05, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
yes! a related bug is that comparing items of two different classes gives
an error (doesn't even return false).
I think if both items are numbers the comparison should be numeric, of
course. (integer 2 == double 2.0 even though the string representations
are
different). Otherwise, it'd be nice to compare on Strings.
Is this in bugzilla? cough... I mean JIRA? It's a pretty easy fix.
(ASTEquals if I remember from memory). Can we get away with this for the
1.5 release or is that a backwards compatibility issue? (1.5 *must* stay
backwards compatible). My first reaction is that this is ok. (since this
wasn't even valid VTL before).
WILL
----- Original Message -----
From: "Nathan Bubna" <[EMAIL PROTECTED]>
To: "Velocity Users List" <velocity-user@jakarta.apache.org>;
<[EMAIL PROTECTED]>
Sent: Friday, September 16, 2005 2:09 PM
Subject: Re: Comparing strings
All good discussion, Henning is, of course, right on.
but all this reminds me of a closely related velocity wish-list item
of mine: having == comparisons be done on the *rendered* value of the
references, rather than the class value. in other words, i would
like:
#set( $two = 2 )
#if( $two == '2' )
to output this text!
#end
after all, putting "$two equals 2" in a template (leave off the #if)
and rendering it will output "2 equals 2". why shouldn't things that
will be rendered identically by VTL be treated as equal in #if
statements? i think that is the most intuitive way to do comparisons
in a template language where the focus is on the rendered output.
perhaps it's time i put a page on the wiki for it, to perhaps build a
little momentum/consensus for getting this in future versions.
On 9/16/05, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
> "Steve O'Hara" <[EMAIL PROTECTED]> writes:
>
> >A while back I chastised someone for not using proper String comparison
> >operators in their templates. I looked in the Velocity code and sure
> >enough "==" operators are translated into equals. So I was looking a
> >bit
> >stupid.
>
> >Somebody challenged me to come up with a situation where the equality
> >"==" operator doesn't work with Strings.
> >Well, finally, I've just found an example in my code;
>
> > #if ($SummarySortField==$Field.getUdmFieldName())
> > #if ($SummarySortField==${Field.getUdmFieldName()})
> > #if ($SummarySortField.equalsIgnoreCase($Field.getUdmFieldName()))
>
> >I thought perhaps I was going mad before when I raised this and plenty
> >of people on this list questioned me, but can anyone explain this?
>
> equalsIngoreCase != equals.
>
> In Java, equals != ==
>
> Look at this:
>
> public class Test {
> public static void main(String [] argv) throws Exception {
> String s1 = "foo";
> String s2 = "foobar".substring(0,3);
>
> System.out.println(s1);
> System.out.println(s2);
> System.out.println(s1 == s2);
> System.out.println(s1.equals(s2));
> }
>
> }
>
> outputs
>
> foo
> foo
> false
> true
>
> However, in Velocity:
>
> --- cut ---
> import java.io.OutputStreamWriter;
>
> import org.apache.commons.lang.ObjectUtils;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.Velocity;
>
> public class Demo {
> public static void main(String[] args) {
> try {
> Velocity.init();
>
> VelocityContext vc = new VelocityContext();
> String s1 = "foo";
> String s2 = "foobar".substring(0,3);
> vc.put("s1", s1);
> vc.put("s2", s2);
>
> vc.put("s1info", ObjectUtils.appendIdentityToString(null,
> s1).toString());
> vc.put("s2info", ObjectUtils.appendIdentityToString(null,
> s2).toString());
>
> Template template = Velocity.getTemplate("DemoTemplate.vm");
> OutputStreamWriter osw = new OutputStreamWriter(System.out);
>
> template.merge(vc, osw);
>
> osw.flush();
> osw.close();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> --- cut ---
>
> String1: ${s1}, Type is $s1.Class.Name
> String2: ${s2}, Type is $s2.Class.Name
>
> String1 Info: ${s1info}
> String2 Info: ${s2info}
>
> Equals:
> #if ($s1.equals($s2))
> True
> #else
> False
> #end
>
> Compare:
> #if ($s1 == $s2)
> True
> #else
> False
> #end
>
> --- cut ---
>
> produces:
>
> String1: foo, Type is java.lang.String
> String2: foo, Type is java.lang.String
>
> String1 Info: [EMAIL PROTECTED]
> String2 Info: [EMAIL PROTECTED]
>
> Equals:
> True
>
> Compare:
> True
>
> So Velocity == is not the same as Java == for Strings. It is the same
> as equals().
>
> Best regards
> Henning
>
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for
> hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> 4 - 8 - 15 - 16 - 23 - 42
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
