Jason Johnston wrote:
> Rhino also makes the JavaScript methods available to Java strings if
> the java.lang.String class doesn't already define them. For example:
>
> js> javaString.match(/a.*/)
Thanks, that clears part of the confusion to me.
It also explains why sometimes I could get away with treating strings
as the language (JavaScript) calls for, while other times I couldn't.
For example match() works the same on both string types, as the example
says, while replace() doesn't. That's just great.
To complicate matters further, I cannot simply wrap a java.lang.String
in a JS String() constructor and call replace() on the resulting object,
because whenever I handle a java.lang.String I must expect to receive a
Java null, but that becomes a JS null, and String(null) == 'null'!
So:
null is false
"" is false
java.lang.String("") is true (!)
String(java.lang.String("")) is false
String(null) is true
Uhh...
I guess I'll have to wrap EVERY Java string in something like this:
function str(javaString) {
if (javaString == null)
return '';
else
return String(javaString);
}
Which means every cocoon.request.get*() call, every string coming from
forms... What a mess!
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
