Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <46D374CA.7080308@lojjic.net>
Date: Mon, 27 Aug 2007 19:05:14 -0600
From: Jason Johnston <cocoon@lojjic.net>
User-Agent: Thunderbird 2.0.0.6 (X11/20070728)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Java strings vs. Javascript strings
References: <20070827100848.GR13664@localhost.localdomain>
 <46D2C885.3090404@lojjic.net> <20070827132727.GT13664@localhost.localdomain>
In-Reply-To: <20070827132727.GT13664@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tobia Conforto wrote:
> 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

Yeah that's definitely not fun. :-)

So digging around in the Rhino API I discovered the WrapFactory 
class[1], which is what Rhino uses to wrap Java objects returned from 
methods so that they can be scripted.  By default it wraps 
java.lang.String objects just like it wraps any other Java object, 
giving your script access to its Java methods.  But it does allow you to 
switch this behavior for "primitive" values (strings, numbers, 
booleans), so that it exposes them as native JavaScript primitives e.g. 
the JavaScript String.

You can flip that switch by adding the following line to your flowscript:

Packages.org.mozilla.javascript.Context.getCurrentContext().getWrapFactory().setJavaPrimitiveWrap(false);

At least in my limited testing this seems to cause any Java String 
values returned from methods to be treated as JavaScript String 
primitives.  For example the replace() method works just fine and it 
shouldn't have the issues with nulls you mentioned earlier.

Give it a try, hope it works for you.
--Jason

[1] 
http://www.mozilla.org/rhino/apidocs/org/mozilla/javascript/WrapFactory.html


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org