Any known issues with the way Rhino works in Servoy

Classic Servoy
1

I’m working on debugging issues I’m having porting the Date.js library to Servoy. See: http://www.datejs.com

For the most part, the library works in Servoy, by just dumping the contents into a global function, and running it to extend the environment. Most of it’s functions extend the Date, Number objects and their prototypes. The test suite passes for these functions.

The exception, however, is the “parse” method, which takes a string and parses a date from it, using some very cool, naturally language friendly constructs. This library is well tested, and runs well in all browsers. It also runs in Rhino – I’ve used the Rhino shell for versions 1.6R7 and 1.7R1 to test my code, and the all the methods behave as expected.

I’ve even run it in the Rhino shell wrapped in a function to make sure I wasn’t adopting any scoping issues from having it wrapped in a global function.

Inside Servoy, however, the parse routine only sort of works. Many standard formats are recognized (like ‘t’ for today, ‘+5 years’, etc.), but date formats and partial date formats do not work…examples, "7/1’, “Jul 1”, etc. – which all work great in Date.js in any other environment, but not in Servoy.

The parse method makes extensive use of regex. I’m working on stepping through the debugger in tandem in Firefox/Firebug, and Servoy, to try to locate places where the logic is breaking down, but was hoping that someone on the engineering team might have some insight on where to look for failure points due to any special issues on the way Rhino is embedded in Servoy.

Thanks for any ideas. I have some very cool stuff to use this library for and will be sure to share them, if I can get past these last few bugs.

greg.

2

Greg,
Some ideas come to mind to think about:
Does Servoy use an old version of regex or a custom version?
Are you able to use a substitute regex wrapped in a plugin for example? (Assuming the plugin regex is “better” or validated with Rhino?).
Does Rhino use of regex depend on some other libs?
Glad to see you working hard at taking the date apart…
Tom

3

I hope that Tano will integrate Rhino 1.7R2 in its final release, that might help integrating third party js libs.

For now, it doesn’t seem to have changed (supposedly it was 1.6R7 in Servoy 4.1.3).

But 1.6R7 release date is 2007-08-20
1.7R2 release date is 2009-03-22.

I would vote for some update, don’t you?

4

Hi patrick,

You definitely have my vote on Rhino 1.7R2 because it would allow us to implement a new (bean) feature that is impossible with the current (Servoy) version of Rhino.

5

patrick: tano will not upgrade to 1.7R2, for us it doesnt bring enough the plate that would deserve the upgrade cost.
1.7R3 is maybe something we would use because of some new internal stuff.

Robert : what feature is that?

6

jcompagner:
Robert : what feature is that?

Inline JavaScript support in the Apache Batik libraries.
Batik ships with Rhino 1.6R5, Servoy uses 1.6R7 and this breaks Batik. But 1.7R2 does work with Batik.

7

ROCLASI:

jcompagner:
Robert : what feature is that?

Inline JavaScript support in the Apache Batik libraries.
Batik ships with Rhino 1.6R5, Servoy uses 1.6R7 and this breaks Batik. But 1.7R2 does work with Batik.

so it did work with 1.6R5, they broke something in 1.6R7 and that was fixed again in 1.7R2?

if you know what it is i think i can patch it for you (that would be way easier the upgrading it)

8

jcompagner:
patrick: tano will not upgrade to 1.7R2, for us it doesnt bring enough the plate that would deserve the upgrade cost.
1.7R3 is maybe something we would use because of some new internal stuff.

Robert : what feature is that?

Do you know when 1.7R3 will be released?

9

jcompagner:

ROCLASI:

jcompagner:
Robert : what feature is that?

Inline JavaScript support in the Apache Batik libraries.
Batik ships with Rhino 1.6R5, Servoy uses 1.6R7 and this breaks Batik. But 1.7R2 does work with Batik.

so it did work with 1.6R5, they broke something in 1.6R7 and that was fixed again in 1.7R2?

if you know what it is i think i can patch it for you (that would be way easier the upgrading it)

Well, in fact Batik breaks whatever the version integrated in Servoy.
Only inline ecmascripts (that uses Rhino) is not working, the rendering is fine.

More precisely everything related to mouse events of type mousedown and mousemove are broken… somehow the Event seems to have been “eaten” by Servoy (or Rhino) before it reaches the inline javascript handler.
When retrieved from Java the event is there, but it is null in the javascript eventHandler: the same script works fine in Batik Squiggle Browser!

I have coded a workaround (every event handling is now done in Java, but for mousemove there is a slight delay (almost unoticeable by the user though) caused by the fact that Batik uses its own Thread for updates, but this is not the real problem.
The real problem is that the ease of integrating inline ECMAScripts in the SVG files is lost because every mouse event handling causes Exceptions…