You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Christophe Jolif <cj...@ilog.fr> on 2000/11/16 10:24:59 UTC
ECMAScript (rhino) and DOM binding
Hi all!
As I already told Vincent, I found a problem in DOM binding + rhino.
Everything works (nearly) automatically and fine, except for one point.
In DOM spec it is required the following piece of script registers the
function as a listener:
myNode.addEventListener("type", myFunction, true)
where:
function myFunction(evt) {
//
}
Rhino default binding doesn't deal with this kind of things, indeed, the
second argument is expected to be an "EventListener" and not a Rhino
function.
There are at least 3 solutions to solve the pb:
-(1) provide our own binding for DOM objects that implements EventTarget
(nearly all objects?).
This solution can be done in two manner:
* (1a) by defining n new classes for n existing DOM classes that
implements (directly or inderectly) EventTarget: very simple but lot of
work and will not work if user extends the DOM (except if he also
defines its own binding classes).
* (1b) by using Proxy from JDK1.3 (that's the solution I have tested):
this dramatically reduces the number of classes (n -> 1 or 2) + still
works if user extends the DOM but has some drawbacks:
+ it works only in JDK1.3
+ to perfectly works we will need to modify the DOM to have
interfaces for everything (Proxy works only for interfaces) [for example
fireDOM... is not defined in an interfaces but only in a class =>
problem].
- (2) modify Rhino source: quite simple but licensing and distrubution
of Rhino source code issues + maintenance problem when rhino evolves.
- (3) modify DOM implementation to add a addEventListener method taking
a javascript function in parameter (I'm not sure it works: I haven't
tested it): easy if it works but creates a dependency between DOM
implementation code and Rhino (depency can be dynamic but...).
Do you have any opinion on the strategy to follow?
My opinion is:
(2) creates two mainy issues to be the right solution
(3) is a kind of hack
(1b) is the ideal one on rhino side (still work when extending DOM) but
need DOM modifications => need opinion from Stephane.
(1a) is the simpliest one. But may take time to implement + not
extensible without coding new classes.
--
Christophe
Re: ECMAScript (rhino) and DOM binding
Posted by Christophe Jolif <cj...@ilog.fr>.
Vincent,
Vincent Hardy wrote:
>
> Christophe,
>
> Christophe Jolif wrote:
> >
> > Vincent,
> >
> > Even after modifying the dom-eventListener BE test without changing its
> > scope, it will be difficult to pass it for the first Batik release.
> > Indeed, the refreshing mechanism when modifying a GVT node is not
> > already in place in the repository. Thierry told me about some tests he
> > does on this but they are not integrated in the repository as some
> > problems still remain. I imitate Thierry's method for the kind of update
> > I need on my local tree, and it seems to work for the BE test but as
> > Thierry is not sure of these modifications I think we should avoid to
> > integrate something similar to this in the repository.
> >
> > By the way, I think It should be one of the priority after the release
> > to discuss about the GVT refreshing mechanism if we want to go further
> > in scripting and animation.
>
> I agree that this is a top priority (along with finishing and cleaning
> up static features). For the BE, I think we should tell the SVG WG we
> will
> not pass it. Do you want me to do it or will you send an email?
> V.
I will send an email. I will also raise the question about
createElement/createElementNS.
--
Christophe
Re: ECMAScript (rhino) and DOM binding
Posted by Dean Jackson <de...@w3.org>.
Just for reference, I talked to Phillipe about this yesterday
(DOM Activity lead). From his reaction it appears this is a well known
problem, and I don't think there is any easy solution.
Dean
> > Even after modifying the dom-eventListener BE test without changing its
> > scope, it will be difficult to pass it for the first Batik release.
> > Indeed, the refreshing mechanism when modifying a GVT node is not
> > already in place in the repository. Thierry told me about some tests he
> > does on this but they are not integrated in the repository as some
> > problems still remain. I imitate Thierry's method for the kind of update
> > I need on my local tree, and it seems to work for the BE test but as
> > Thierry is not sure of these modifications I think we should avoid to
> > integrate something similar to this in the repository.
> >
> > By the way, I think It should be one of the priority after the release
> > to discuss about the GVT refreshing mechanism if we want to go further
> > in scripting and animation.
>
> I agree that this is a top priority (along with finishing and cleaning
> up static features). For the BE, I think we should tell the SVG WG we
> will
> not pass it. Do you want me to do it or will you send an email?
> V.
>
> >
> > vincent hardy wrote:
> > >
> > > Christophe,
> > >
> > > I vote for:
> > >
> > > a. No hack.
> > > b. If we cannot pass the test, just say so to the WG.
> > > or
> > > c. If the BE modification does not change the intent/scope of the BE,
> > > then
> > > I think it is fair to ask for a test modification to pass it.
> > >
> > > V.
> > > Christophe Jolif wrote:
> > > >
> > > > Hi all!
> > > >
> > > > > I will tell you tomorrow if Proxy & DOM modification can surely be
> > > > > removed to implement (1b).
> > > >
> > > > Ok. I implemented (1b) without DOM modifications & without using a Proxy
> > > > by subclassing Rhino classes (still to be clean but it works).
> > > >
> > > > Then, I tried to load dom-eventListeners-BE-04.svg (as we promised to be
> > > > ok on that one at previous f2f SVG WG), but there are two problems:
> > > >
> > > > - the script do the following var newText = doc.createElement("text")
> > > > that returns a instance of GenericElement and not an instance of
> > > > SVGTextElement => in the automatic insert update (done by Emmanuel
> > > > during the Hackaton), we look for a bridge for the GenericElement
> > > > (global namespace, "text") and of course we can't find it [we have a
> > > > bridge only for (svg namespace, "text")]. If I look at the Batik SVG
> > > > DOM, it seems that to get an actual SVGTextElement we should call
> > > > createElementNS(svg_namespace, "svg:text"). If I read the DOM spec it
> > > > seems that Batik SVG DOM behavior is ok => maybe the test should be
> > > > modified. Vincent as you wrote the test you may have an opinion on this?
> > > >
> > > > - the button.setAttribute("style", "visibility:hidden") line that has no
> > > > effects in Batik.
> > > >
> > > > I think we can solve the first problem by modifying the one that is
> > > > wrong (the test or the DOM impl) but for the second problem there are no
> > > > clean solutions since we don't have dynamic stuff on CSS. Then two
> > > > solutions:
> > > >
> > > > - implement a hack to let it work.
> > > > - we finally come back on our promise to pass the test.
> > > > - we ask to the WG to remove the "visibility:hidden" that is not really
> > > > the purpose of the test (and to change the resulting PNG).
> > > >
> > > > --
> > > > Christophe
> > >
> > > --
> > > +-----------------------------------------------------------+
> > > | Vincent Hardy vincent.hardy@eng.sun.com |
> > > | Scalable Vector Graphics XML Technology Center |
> > > | 650-786-4066 Menlo Park, CA, USA |
> > > +-----------------------------------------------------------+
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: batik-dev-help@xml.apache.org
> >
> > --
> > Christophe
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: batik-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: ECMAScript (rhino) and DOM binding
Posted by Vincent Hardy <vi...@eng.sun.com>.
Christophe,
Christophe Jolif wrote:
>
> Vincent,
>
> Even after modifying the dom-eventListener BE test without changing its
> scope, it will be difficult to pass it for the first Batik release.
> Indeed, the refreshing mechanism when modifying a GVT node is not
> already in place in the repository. Thierry told me about some tests he
> does on this but they are not integrated in the repository as some
> problems still remain. I imitate Thierry's method for the kind of update
> I need on my local tree, and it seems to work for the BE test but as
> Thierry is not sure of these modifications I think we should avoid to
> integrate something similar to this in the repository.
>
> By the way, I think It should be one of the priority after the release
> to discuss about the GVT refreshing mechanism if we want to go further
> in scripting and animation.
I agree that this is a top priority (along with finishing and cleaning
up static features). For the BE, I think we should tell the SVG WG we
will
not pass it. Do you want me to do it or will you send an email?
V.
>
> vincent hardy wrote:
> >
> > Christophe,
> >
> > I vote for:
> >
> > a. No hack.
> > b. If we cannot pass the test, just say so to the WG.
> > or
> > c. If the BE modification does not change the intent/scope of the BE,
> > then
> > I think it is fair to ask for a test modification to pass it.
> >
> > V.
> > Christophe Jolif wrote:
> > >
> > > Hi all!
> > >
> > > > I will tell you tomorrow if Proxy & DOM modification can surely be
> > > > removed to implement (1b).
> > >
> > > Ok. I implemented (1b) without DOM modifications & without using a Proxy
> > > by subclassing Rhino classes (still to be clean but it works).
> > >
> > > Then, I tried to load dom-eventListeners-BE-04.svg (as we promised to be
> > > ok on that one at previous f2f SVG WG), but there are two problems:
> > >
> > > - the script do the following var newText = doc.createElement("text")
> > > that returns a instance of GenericElement and not an instance of
> > > SVGTextElement => in the automatic insert update (done by Emmanuel
> > > during the Hackaton), we look for a bridge for the GenericElement
> > > (global namespace, "text") and of course we can't find it [we have a
> > > bridge only for (svg namespace, "text")]. If I look at the Batik SVG
> > > DOM, it seems that to get an actual SVGTextElement we should call
> > > createElementNS(svg_namespace, "svg:text"). If I read the DOM spec it
> > > seems that Batik SVG DOM behavior is ok => maybe the test should be
> > > modified. Vincent as you wrote the test you may have an opinion on this?
> > >
> > > - the button.setAttribute("style", "visibility:hidden") line that has no
> > > effects in Batik.
> > >
> > > I think we can solve the first problem by modifying the one that is
> > > wrong (the test or the DOM impl) but for the second problem there are no
> > > clean solutions since we don't have dynamic stuff on CSS. Then two
> > > solutions:
> > >
> > > - implement a hack to let it work.
> > > - we finally come back on our promise to pass the test.
> > > - we ask to the WG to remove the "visibility:hidden" that is not really
> > > the purpose of the test (and to change the resulting PNG).
> > >
> > > --
> > > Christophe
> >
> > --
> > +-----------------------------------------------------------+
> > | Vincent Hardy vincent.hardy@eng.sun.com |
> > | Scalable Vector Graphics XML Technology Center |
> > | 650-786-4066 Menlo Park, CA, USA |
> > +-----------------------------------------------------------+
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: batik-dev-help@xml.apache.org
>
> --
> Christophe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: ECMAScript (rhino) and DOM binding
Posted by Christophe Jolif <cj...@ilog.fr>.
Vincent,
Even after modifying the dom-eventListener BE test without changing its
scope, it will be difficult to pass it for the first Batik release.
Indeed, the refreshing mechanism when modifying a GVT node is not
already in place in the repository. Thierry told me about some tests he
does on this but they are not integrated in the repository as some
problems still remain. I imitate Thierry's method for the kind of update
I need on my local tree, and it seems to work for the BE test but as
Thierry is not sure of these modifications I think we should avoid to
integrate something similar to this in the repository.
By the way, I think It should be one of the priority after the release
to discuss about the GVT refreshing mechanism if we want to go further
in scripting and animation.
vincent hardy wrote:
>
> Christophe,
>
> I vote for:
>
> a. No hack.
> b. If we cannot pass the test, just say so to the WG.
> or
> c. If the BE modification does not change the intent/scope of the BE,
> then
> I think it is fair to ask for a test modification to pass it.
>
> V.
> Christophe Jolif wrote:
> >
> > Hi all!
> >
> > > I will tell you tomorrow if Proxy & DOM modification can surely be
> > > removed to implement (1b).
> >
> > Ok. I implemented (1b) without DOM modifications & without using a Proxy
> > by subclassing Rhino classes (still to be clean but it works).
> >
> > Then, I tried to load dom-eventListeners-BE-04.svg (as we promised to be
> > ok on that one at previous f2f SVG WG), but there are two problems:
> >
> > - the script do the following var newText = doc.createElement("text")
> > that returns a instance of GenericElement and not an instance of
> > SVGTextElement => in the automatic insert update (done by Emmanuel
> > during the Hackaton), we look for a bridge for the GenericElement
> > (global namespace, "text") and of course we can't find it [we have a
> > bridge only for (svg namespace, "text")]. If I look at the Batik SVG
> > DOM, it seems that to get an actual SVGTextElement we should call
> > createElementNS(svg_namespace, "svg:text"). If I read the DOM spec it
> > seems that Batik SVG DOM behavior is ok => maybe the test should be
> > modified. Vincent as you wrote the test you may have an opinion on this?
> >
> > - the button.setAttribute("style", "visibility:hidden") line that has no
> > effects in Batik.
> >
> > I think we can solve the first problem by modifying the one that is
> > wrong (the test or the DOM impl) but for the second problem there are no
> > clean solutions since we don't have dynamic stuff on CSS. Then two
> > solutions:
> >
> > - implement a hack to let it work.
> > - we finally come back on our promise to pass the test.
> > - we ask to the WG to remove the "visibility:hidden" that is not really
> > the purpose of the test (and to change the resulting PNG).
> >
> > --
> > Christophe
>
> --
> +-----------------------------------------------------------+
> | Vincent Hardy vincent.hardy@eng.sun.com |
> | Scalable Vector Graphics XML Technology Center |
> | 650-786-4066 Menlo Park, CA, USA |
> +-----------------------------------------------------------+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
--
Christophe
Re: ECMAScript (rhino) and DOM binding
Posted by vincent hardy <vi...@eng.sun.com>.
Christophe,
I vote for:
a. No hack.
b. If we cannot pass the test, just say so to the WG.
or
c. If the BE modification does not change the intent/scope of the BE,
then
I think it is fair to ask for a test modification to pass it.
V.
Christophe Jolif wrote:
>
> Hi all!
>
> > I will tell you tomorrow if Proxy & DOM modification can surely be
> > removed to implement (1b).
>
> Ok. I implemented (1b) without DOM modifications & without using a Proxy
> by subclassing Rhino classes (still to be clean but it works).
>
> Then, I tried to load dom-eventListeners-BE-04.svg (as we promised to be
> ok on that one at previous f2f SVG WG), but there are two problems:
>
> - the script do the following var newText = doc.createElement("text")
> that returns a instance of GenericElement and not an instance of
> SVGTextElement => in the automatic insert update (done by Emmanuel
> during the Hackaton), we look for a bridge for the GenericElement
> (global namespace, "text") and of course we can't find it [we have a
> bridge only for (svg namespace, "text")]. If I look at the Batik SVG
> DOM, it seems that to get an actual SVGTextElement we should call
> createElementNS(svg_namespace, "svg:text"). If I read the DOM spec it
> seems that Batik SVG DOM behavior is ok => maybe the test should be
> modified. Vincent as you wrote the test you may have an opinion on this?
>
> - the button.setAttribute("style", "visibility:hidden") line that has no
> effects in Batik.
>
> I think we can solve the first problem by modifying the one that is
> wrong (the test or the DOM impl) but for the second problem there are no
> clean solutions since we don't have dynamic stuff on CSS. Then two
> solutions:
>
> - implement a hack to let it work.
> - we finally come back on our promise to pass the test.
> - we ask to the WG to remove the "visibility:hidden" that is not really
> the purpose of the test (and to change the resulting PNG).
>
> --
> Christophe
--
+-----------------------------------------------------------+
| Vincent Hardy vincent.hardy@eng.sun.com |
| Scalable Vector Graphics XML Technology Center |
| 650-786-4066 Menlo Park, CA, USA |
+-----------------------------------------------------------+
Re: ECMAScript (rhino) and DOM binding
Posted by Christophe Jolif <cj...@ilog.fr>.
Hi all!
> I will tell you tomorrow if Proxy & DOM modification can surely be
> removed to implement (1b).
Ok. I implemented (1b) without DOM modifications & without using a Proxy
by subclassing Rhino classes (still to be clean but it works).
Then, I tried to load dom-eventListeners-BE-04.svg (as we promised to be
ok on that one at previous f2f SVG WG), but there are two problems:
- the script do the following var newText = doc.createElement("text")
that returns a instance of GenericElement and not an instance of
SVGTextElement => in the automatic insert update (done by Emmanuel
during the Hackaton), we look for a bridge for the GenericElement
(global namespace, "text") and of course we can't find it [we have a
bridge only for (svg namespace, "text")]. If I look at the Batik SVG
DOM, it seems that to get an actual SVGTextElement we should call
createElementNS(svg_namespace, "svg:text"). If I read the DOM spec it
seems that Batik SVG DOM behavior is ok => maybe the test should be
modified. Vincent as you wrote the test you may have an opinion on this?
- the button.setAttribute("style", "visibility:hidden") line that has no
effects in Batik.
I think we can solve the first problem by modifying the one that is
wrong (the test or the DOM impl) but for the second problem there are no
clean solutions since we don't have dynamic stuff on CSS. Then two
solutions:
- implement a hack to let it work.
- we finally come back on our promise to pass the test.
- we ask to the WG to remove the "visibility:hidden" that is not really
the purpose of the test (and to change the resulting PNG).
--
Christophe
Re: ECMAScript (rhino) and DOM binding
Posted by Christophe Jolif <cj...@ilog.fr>.
Stephane Hillion wrote:
>
> Christophe Jolif wrote:
>
> > No, you actually missed something. Rhino is ok with this, so we are ok
> > with the spec about this. The only major problem I found and that it
> > will be cool to workaround (for example to pass the
> > dom-eventListeners-BE-04.svg test) is the one I described previously.
>
> Ok, I think I understand now: Rhino implicitely transform 'getXXX' to 'xXX', but
> when the signature of a method changes beetween Java bindings and Javascript
> bindings, there is a problem.
Yes but for DOM & SVG, both are automatically generated from the same
IDL => there should not be such problem using the implicit mechanism.
> So to answer to your previous mail, I am OK for (1b) (DOM modifications), but do
> we want jdk1.3 dependencies?
After going deeper in Rhino code, I think it may be possible to
workaround the problem from the outside, and then it will not be anymore
necessary to modify the DOM and to use a Proxy (1b)!
In this condition I vote for (1b). And even if we should rely on jdk1.3
(if it happens that the Proxy is necessary), I would also vote for (1b).
In general I'm against jdk1.3 dependencies. But in this case I think
that we can have a 98% ECMAScript support in 1.2.x and have the full
support (with the specific addEventListener trick) on jdk1.3. If it
seems that users require full support for jdk1.2.x, we will ask them
resources to write the ~70 classes that should be written (yes I count
them :-). I will also modify build.xml to be able to build and run batik
in 1.2.2 without hacking something, so it will be transparent for the
user.
I will tell you tomorrow if Proxy & DOM modification can surely be
removed to implement (1b).
--
Christophe
Re: ECMAScript (rhino) and DOM binding
Posted by Stephane Hillion <St...@sophia.inria.fr>.
Christophe Jolif wrote:
> No, you actually missed something. Rhino is ok with this, so we are ok
> with the spec about this. The only major problem I found and that it
> will be cool to workaround (for example to pass the
> dom-eventListeners-BE-04.svg test) is the one I described previously.
Ok, I think I understand now: Rhino implicitely transform 'getXXX' to 'xXX', but
when the signature of a method changes beetween Java bindings and Javascript
bindings, there is a problem.
So to answer to your previous mail, I am OK for (1b) (DOM modifications), but do
we want jdk1.3 dependencies?
--
Stephane.
Re: ECMAScript (rhino) and DOM binding
Posted by Christophe Jolif <cj...@ilog.fr>.
Stephane,
Stephane Hillion wrote:
>
> Christophe Jolif wrote:
> Hm.. not sure..
> The following code comes from the spec:
>
> function StartAnimation(evt) {
> text_element = evt.target.ownerDocument.getElementById("TextElement");
> ShowAndGrowElement();
> }
>
> If I do not miss something, this code do not work with rhino. Instead we
> must type (because we use the Java bindings):
>
> function StartAnimation(evt) {
> text_element =
> evt.getTarget().getOwnerDocument().getElementById("TextElement");
> ShowAndGrowElement();
> }
No, you actually missed something. Rhino is ok with this, so we are ok
with the spec about this. The only major problem I found and that it
will be cool to workaround (for example to pass the
dom-eventListeners-BE-04.svg test) is the one I described previously.
> And we have the same problem with each scripting language (and python which
> is not a language but a nightmare ;).
For other languages than ECMAScript (or Java), it is not specified how
it should work, so we can use the way the engine works, it is not really
a problem... But for ECMAScript we should try to respect the specified
way.
--
Christophe
Re: ECMAScript (rhino) and DOM binding
Posted by Stephane Hillion <St...@sophia.inria.fr>.
Christophe Jolif wrote:
> Hi all!
>
> As I already told Vincent, I found a problem in DOM binding + rhino.
> Everything works (nearly) automatically and fine, except for one point.
Hm.. not sure..
The following code comes from the spec:
function StartAnimation(evt) {
text_element = evt.target.ownerDocument.getElementById("TextElement");
ShowAndGrowElement();
}
If I do not miss something, this code do not work with rhino. Instead we
must type (because we use the Java bindings):
function StartAnimation(evt) {
text_element =
evt.getTarget().getOwnerDocument().getElementById("TextElement");
ShowAndGrowElement();
}
And we have the same problem with each scripting language (and python which
is not a language but a nightmare ;).
> In DOM spec it is required the following piece of script registers the
> function as a listener:
>
> myNode.addEventListener("type", myFunction, true)
>
> where:
>
> function myFunction(evt) {
> //
> }
>
> Rhino default binding doesn't deal with this kind of things, indeed, the
> second argument is expected to be an "EventListener" and not a Rhino
> function.
>
> There are at least 3 solutions to solve the pb:
>
> -(1) provide our own binding for DOM objects that implements EventTarget
> (nearly all objects?).
>
> This solution can be done in two manner:
>
> * (1a) by defining n new classes for n existing DOM classes that
> implements (directly or inderectly) EventTarget: very simple but lot of
> work and will not work if user extends the DOM (except if he also
> defines its own binding classes).
> * (1b) by using Proxy from JDK1.3 (that's the solution I have tested):
> this dramatically reduces the number of classes (n -> 1 or 2) + still
> works if user extends the DOM but has some drawbacks:
> + it works only in JDK1.3
> + to perfectly works we will need to modify the DOM to have
> interfaces for everything (Proxy works only for interfaces) [for example
> fireDOM... is not defined in an interfaces but only in a class =>
> problem].
>
> - (2) modify Rhino source: quite simple but licensing and distrubution
> of Rhino source code issues + maintenance problem when rhino evolves.
>
> - (3) modify DOM implementation to add a addEventListener method taking
> a javascript function in parameter (I'm not sure it works: I haven't
> tested it): easy if it works but creates a dependency between DOM
> implementation code and Rhino (depency can be dynamic but...).
>
> Do you have any opinion on the strategy to follow?
>
> My opinion is:
>
> (2) creates two mainy issues to be the right solution
> (3) is a kind of hack
> (1b) is the ideal one on rhino side (still work when extending DOM) but
> need DOM modifications => need opinion from Stephane.
> (1a) is the simpliest one. But may take time to implement + not
> extensible without coding new classes.
I think we have no choice: this is the only working solution: one set of
binding per scripting language.
--
Stephane.