specialist33 said:
> Nathan Bubna wrote:
> > specialist33 said:
> >
> >>I'm getting an incomprehensible "is not a valid ref" error. I've spent
> >>some hours trying to solve it, but I'm not being helped by the fact that
> >>I cannot seem to find a way of getting velocity to tell me what WOULD be
> >>a valid reference or WHY this is not a valid ref.
> >>
> >>summary == [it's a public method in a public class,
> >>and i'm doing the VTL syntax properly,
> >>but still getting error messages. help!]
> >
> > ...
> >
> > ok, i agree. you've got the public, public, public thing down, and you're
> > getting most of your references right, so i either don't have a clue what
the
> > problem is or else your getLogin() method is returning null. can you
> assure
> > us that the latter is not the case?
>
> It was sometimes returning null, so I made it forced return something
> (in this case the string "unquoted3" (quotes only there to illustrate,
> as the name suggests the value had no quotes ;)). That produced the
> following log statements:
>
> [INFO]-I just put currentAccount = [EMAIL PROTECTED] into
> the context with getLogin = unquoted3
>
> [INFO]-ResourceManager : found testcookie with loader
> org.apache.velocity.runtime.resource.loader.FileResourceLoader
>
> [WARN]-org.apache.velocity.runtime.exception.ReferenceException:
> reference : template = testcookie [line 9,column 52] : $account.getLogin
> is not a valid reference.
$account.getLogin is not a valid reference. :) but $account.Login,
$account.login, and $account.getLogin() are now, right?
> (note that "testcookie" is the literal name of the template file being
> used here).
>
> > problem is or else your getLogin() method is returning null. can you
> assure
>
> ! This possibility entirely passed me by (its probably in the docs and I
> just didn't notice it, but it's very counter-intuitive),
:)
> and sounds like
> a serious problem in it's own right. If a null return value produces
> this error message too, then the error message is horribly unfair to the
> standard non-velocity java programmer... Java as a language has a
> fundamental philosophy of explicitly catching and outputting an error
> message on null's, leading to "NullPointerException" being one of the
> most frequently encountered for novice/intermediate programmers (and
> maybe it shouldn't, but the fact is it does, and people kind of expect
> java systems to honour that philosophy).
i'm gonna disagree here. VTL (velocity template language) is not java and
should not be expected to be so. please note that it will respond precisely
the same if $account itself is null. it's just trying to tell you that the
reference, whether ${ref} or ${obj.ref} is not going to render properly.
this is why silent notation (e.g. $!ref) exists. if you just do $ref and it
is null, then the user will see $ref in the template. this is bad practice
and could potentially even expose sensitive information about the inner
workings of your app. so, if you have a reference (whether $ref or $obj.ref)
that you can reasonably expect to return or be null, then you should be using
silent notation. this is essentially what the warning is trying to tell you,
though i readily confess that it isn't clear from the message.
> That error message ought at least to make explicit mention of null as a
> possible cause, since null is OFTEN a valid return value for
> applications - there is nothing wrong with logic that returns a null
> value in a java app, but velocity silently kills it. I can see the
> argument that in a templating engine perhaps null should never be
> returned - but that assumes this templating engine will never be
> attached to another system, and AFAICS velocity is proving extremely
> popular for attaching to other systems?
but there can be something wrong with displaying unrendered references in a
template language. thus the warning message.
> I'm guessing an even better approach would be two separate messages, one
> for the "couldn't find a method" and another for "found a method but it
> returned null", and in both cases it ought to say what the method name
> it found (or tried to find) was. That would shortcut the debugging
> process considerably, and probably reduce the number of people in my
> situation who even needed to come to the list to ask for help :).
yeah, that sounds like a worthy enhancement request. i'd recommend filing a
bug report on it so it doesn't get forgotten. and, of course, if you can come
up with a patch to go with it, that would be cool too. i can't say whether
it'll ever be applied, but i think this is a good idea.
Nathan Bubna
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
