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]
