You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Tobia Conforto <to...@linux.it> on 2007/08/27 12:08:49 UTC
Java strings vs. Javascript strings
Hello
Am I the only Cocoon user who is extremely annoyed by the fact that Java
strings are not Javascript strings are not Java strings?
Depending on the context, in your Flowscript you have to use either:
str.startsWith("...")
str.length()
str.codePointAt(n)
and the rest of java.lang.String methods, or:
str.match(/^.../)
str.length
str.charCodeAt(n)
and the rest of Javascript String methods.
This is very annoying and a huge waste of time, at least for me.
I found that I can wrap every string in a Javascript String(...)
constructor, so the following always work:
String(str).match(/^.../)
String(str).length
String(str).charCodeAt(n)
But it's ugly, repetitive, and prone to errors.
And don't get me started on testing for a null value or void string!
This is giving me headaches.
Can't Rhino, or whatever piece of software is bridging Javascript to Java,
do the Right Thing and present every string as a Javascript string when
I'm programming in Javascript? Can it be configured to do so?
Am I doing something wrong?
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Java strings vs. Javascript strings
Posted by Jason Johnston <co...@lojjic.net>.
On Tue, 28 Aug 2007 20:36:09 +0200, Grzegorz Kossakowski
<gk...@apache.org> wrote:
>> FYI I personally would vote against making it the default,
>> partly because I prefer the framework not do unexpected magic
> conversions,
>> but mostly because it's a backward-incompatible change and would break
> lots
>> of existing flowscript code. I would, however, be in support of making
> it
>> easier to set the javaPrimitiveWrap configuration, perhaps on a more
>> granular basis rather than globally if possible.
>
> Jason, are you strong in your opinion about not making it default?
I could probably be convinced otherwise, as long as it's easy to restore
the current behavior; let's see what others think.
> I think we could make it default in Cocoon 2.2 as it's not considered to
> be fully
> backwards-compatible and make it easy to switch to previous behaviour.
> Default settings should
> reflect what majority of people (including users) think is reasonable.
I'm
> rather surprised that it
> this javaPrimitiveWrap option is not enabled already.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Java strings vs. Javascript strings
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jason Johnston pisze:
>> I'd like to suggest making it the default in Cocoon.
>> Should I post an issue to JIRA or a message to the dev mailing list?
>
> I'd suggest bringing it up on the dev list to see if there is developer
> support for it.
Definitively.
> FYI I personally would vote against making it the default,
> partly because I prefer the framework not do unexpected magic conversions,
> but mostly because it's a backward-incompatible change and would break lots
> of existing flowscript code. I would, however, be in support of making it
> easier to set the javaPrimitiveWrap configuration, perhaps on a more
> granular basis rather than globally if possible.
Jason, are you strong in your opinion about not making it default?
I think we could make it default in Cocoon 2.2 as it's not considered to be fully
backwards-compatible and make it easy to switch to previous behaviour. Default settings should
reflect what majority of people (including users) think is reasonable. I'm rather surprised that it
this javaPrimitiveWrap option is not enabled already.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Java strings vs. Javascript strings
Posted by Jason Johnston <co...@lojjic.net>.
On Tue, 28 Aug 2007 16:25:25 +0200, Tobia Conforto
<to...@linux.it> wrote:
>>
Packages.org.mozilla.javascript.Context.getCurrentContext().getWrapFactory().setJavaPrimitiveWrap(false);
>
> Thank you! This is going to be a noticeable time saver for us, by
> eliminating lots of small errors.
Great! Glad to hear it worked for you.
> I'd like to suggest making it the default in Cocoon.
> Should I post an issue to JIRA or a message to the dev mailing list?
I'd suggest bringing it up on the dev list to see if there is developer
support for it. FYI I personally would vote against making it the default,
partly because I prefer the framework not do unexpected magic conversions,
but mostly because it's a backward-incompatible change and would break lots
of existing flowscript code. I would, however, be in support of making it
easier to set the javaPrimitiveWrap configuration, perhaps on a more
granular basis rather than globally if possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Java strings vs. Javascript strings
Posted by Tobia Conforto <to...@linux.it>.
Jason Johnston wrote:
> 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
>
> Packages.org.mozilla.javascript.Context.getCurrentContext().getWrapFactory().setJavaPrimitiveWrap(false);
Thank you! This is going to be a noticeable time saver for us, by
eliminating lots of small errors.
IMHO dynamic languages such as JavaScript are less expensive to program
in than statically typed ones like Java, at least for small- to
medium-sized projects. But only if Things Just Workâ˘, and having to
deal with only one class of primitive types is part of it.
I'd like to suggest making it the default in Cocoon.
Should I post an issue to JIRA or a message to the dev mailing list?
Tobia
> [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
Re: Java strings vs. Javascript strings
Posted by Jason Johnston <co...@lojjic.net>.
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
Re: Java strings vs. Javascript strings
Posted by Tobia Conforto <to...@linux.it>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Java strings vs. Javascript strings
Posted by Jason Johnston <co...@lojjic.net>.
Tobia Conforto wrote:
> Hello
>
> Am I the only Cocoon user who is extremely annoyed by the fact that Java
> strings are not Javascript strings are not Java strings?
>
...
>
> Can't Rhino, or whatever piece of software is bridging Javascript to Java,
> do the Right Thing and present every string as a Javascript string when
> I'm programming in Javascript? Can it be configured to do so?
According to the Rhino documentation[1]:
"
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.*/)
ava
"
Does that shortcut behavior work for you? If so, you could just stick
to the JS String methods regardless of the type; does that solve your
headaches?
--Jason
[1] http://www.mozilla.org/rhino/ScriptingJava.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org