Script-tag name conflicts

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Script-tag name conflicts

ramzi.abbyad
Hello,

Please let me know if this issue is something that can be addressed on
your end rather than ours.

In chrome, when we are debugging,  our project does not minify and
concatenate the JS files.  The result is that we get script tags in the
DOM with the same "id" attributes as the serverside java classes that
we are loading- thus making it easier to lookup files for debugging.

The problem is that when the DWR client stubs get generated each stub
calls the dwr.engine._getObject function which checks the global scope
for remoted classes.  In chrome, however, the window object contains
references to all script tags loaded and this causes a namespace
conflict.  For example for:

dwr.engine._global['MethodName']

returns

<script id="MethodName" type="text/javascript" src="path"></script>

and hence the check for undefined fails and the object never gets set.

To elaborate, the fix I wrote to address this is provided in the first
conditional below:

  dwr.engine._getObject = function(prop) {
    //return undefined;
    if(dwr.engine._global[prop] && dwr.engine._global[prop].tagName &&
dwr.engine._global[prop].tagName === "SCRIPT") return undefined;
    var parts = prop.split(".");
    var value;
    var scope = dwr.engine._global;
    while(parts.length > 0) {
      var currprop = parts.shift();
      value = scope[currprop];
      if (parts.length > 0 && value == null) return undefined;
      scope = value;
    }
    return value;
  };

Thanks very much for your help.

Regards,
Ramzi
Reply | Threaded
Open this post in threaded view
|

Re: Script-tag name conflicts

Mike Wilson
Administrator
Just so I understand what you are showing here:
- you are adding id:s on script tags yourselves, right?
- the problem goes away if you remove these id:s, right?
- why do you need these id:s?

Best regards
Mike Wilson

Ramzi wrote:

> Hello,
>
> Please let me know if this issue is something that can be addressed on
> your end rather than ours.
>
> In chrome, when we are debugging,  our project does not minify and
> concatenate the JS files.  The result is that we get script
> tags in the
> DOM with the same "id" attributes as the serverside java classes that
> we are loading- thus making it easier to lookup files for debugging.
>
> The problem is that when the DWR client stubs get generated each stub
> calls the dwr.engine._getObject function which checks the global scope
> for remoted classes.  In chrome, however, the window object contains
> references to all script tags loaded and this causes a namespace
> conflict.  For example for:
>
> dwr.engine._global['MethodName']
>
> returns
>
> <script id="MethodName" type="text/javascript" src="path"></script>
>
> and hence the check for undefined fails and the object never gets set.
>
> To elaborate, the fix I wrote to address this is provided in the first
> conditional below:
>
>   dwr.engine._getObject = function(prop) {
>     //return undefined;
>     if(dwr.engine._global[prop] && dwr.engine._global[prop].tagName &&
> dwr.engine._global[prop].tagName === "SCRIPT") return undefined;
>     var parts = prop.split(".");
>     var value;
>     var scope = dwr.engine._global;
>     while(parts.length > 0) {
>       var currprop = parts.shift();
>       value = scope[currprop];
>       if (parts.length > 0 && value == null) return undefined;
>       scope = value;
>     }
>     return value;
>   };
>
> Thanks very much for your help.
>
> Regards,
> Ramzi

Reply | Threaded
Open this post in threaded view
|

Re: Script-tag name conflicts

ramzi.abbyad
We are currently upgrading from DWR2 to DWR3.

We could change the IDs, but in the interest of making the code backwards compatible, I thought I would bring this issue to your attention.

Ramzi

-----Original Message-----
From: Mike Wilson [mailto:[hidden email]]
Sent: Monday, April 27, 2015 10:59 AM
To: [hidden email]
Subject: [dwr-users] Re: Script-tag name conflicts

Just so I understand what you are showing here:
- you are adding id:s on script tags yourselves, right?
- the problem goes away if you remove these id:s, right?
- why do you need these id:s?

Best regards
Mike Wilson

Ramzi wrote:

> Hello,
>
> Please let me know if this issue is something that can be addressed on
> your end rather than ours.
>
> In chrome, when we are debugging,  our project does not minify and
> concatenate the JS files.  The result is that we get script tags in
> the DOM with the same "id" attributes as the serverside java classes
> that we are loading- thus making it easier to lookup files for
> debugging.
>
> The problem is that when the DWR client stubs get generated each stub
> calls the dwr.engine._getObject function which checks the global scope
> for remoted classes.  In chrome, however, the window object contains
> references to all script tags loaded and this causes a namespace
> conflict.  For example for:
>
> dwr.engine._global['MethodName']
>
> returns
>
> <script id="MethodName" type="text/javascript" src="path"></script>
>
> and hence the check for undefined fails and the object never gets set.
>
> To elaborate, the fix I wrote to address this is provided in the first
> conditional below:
>
>   dwr.engine._getObject = function(prop) {
>     //return undefined;
>     if(dwr.engine._global[prop] && dwr.engine._global[prop].tagName &&
> dwr.engine._global[prop].tagName === "SCRIPT") return undefined;
>     var parts = prop.split(".");
>     var value;
>     var scope = dwr.engine._global;
>     while(parts.length > 0) {
>       var currprop = parts.shift();
>       value = scope[currprop];
>       if (parts.length > 0 && value == null) return undefined;
>       scope = value;
>     }
>     return value;
>   };
>
> Thanks very much for your help.
>
> Regards,
> Ramzi

Reply | Threaded
Open this post in threaded view
|

Re: Script-tag name conflicts

Mike Wilson
Administrator
This behaviour isn't new - it has been in IE since beginning of time. And it
doesn't affect just script elements but any element with an id.
Basically you have to choose a way to avoid having these kinds of conflicts.
Your proposed fix will only move the error further down the line as
_getObject will not return the desired value.

DWR already offers several ways to solve this problem but it can never do
anything about the case where your code chooses to use the same global name
for two different things.

Possible solutions include:

1) Use naming conventions so element id:s and javascript variables (f ex DWR
remote interfaces) never collide.

2) Avoid adding DWR entities to the top-level namespace by using package
notation (javascript="mypackage.MyRemoteService") so only your top package
is exposed on the global object.

3) Avoid adding DWR entities to the global object at all by using the AMD
loader integration (not currently in docs, see usage on
https://directwebremoting.atlassian.net/browse/DWR-515)

Best regards
Mike

Ramzi wrote:

> We are currently upgrading from DWR2 to DWR3.
>
> We could change the IDs, but in the interest of making the
> code backwards compatible, I thought I would bring this issue
> to your attention.
>
> Ramzi
>
> -----Original Message-----
> From: Mike Wilson [mailto:[hidden email]]
> Sent: Monday, April 27, 2015 10:59 AM
> To: [hidden email]
> Subject: [dwr-users] Re: Script-tag name conflicts
>
> Just so I understand what you are showing here:
> - you are adding id:s on script tags yourselves, right?
> - the problem goes away if you remove these id:s, right?
> - why do you need these id:s?
>
> Best regards
> Mike Wilson
>
> Ramzi wrote:
> > Hello,
> >
> > Please let me know if this issue is something that can be
> addressed on
> > your end rather than ours.
> >
> > In chrome, when we are debugging,  our project does not minify and
> > concatenate the JS files.  The result is that we get script tags in
> > the DOM with the same "id" attributes as the serverside
> java classes
> > that we are loading- thus making it easier to lookup files for
> > debugging.
> >
> > The problem is that when the DWR client stubs get generated
> each stub
> > calls the dwr.engine._getObject function which checks the
> global scope
> > for remoted classes.  In chrome, however, the window object
> contains
> > references to all script tags loaded and this causes a namespace
> > conflict.  For example for:
> >
> > dwr.engine._global['MethodName']
> >
> > returns
> >
> > <script id="MethodName" type="text/javascript" src="path"></script>
> >
> > and hence the check for undefined fails and the object
> never gets set.
> >
> > To elaborate, the fix I wrote to address this is provided
> in the first
> > conditional below:
> >
> >   dwr.engine._getObject = function(prop) {
> >     //return undefined;
> >     if(dwr.engine._global[prop] &&
> dwr.engine._global[prop].tagName &&
> > dwr.engine._global[prop].tagName === "SCRIPT") return undefined;
> >     var parts = prop.split(".");
> >     var value;
> >     var scope = dwr.engine._global;
> >     while(parts.length > 0) {
> >       var currprop = parts.shift();
> >       value = scope[currprop];
> >       if (parts.length > 0 && value == null) return undefined;
> >       scope = value;
> >     }
> >     return value;
> >   };
> >
> > Thanks very much for your help.
> >
> > Regards,
> > Ramzi
>

Reply | Threaded
Open this post in threaded view
|

Re: Script-tag name conflicts

Mike Wilson
Administrator
In reply to this post by ramzi.abbyad
Ah sorry Ramzi, I probably misunderstood you before. You are suggesting that
DWR should overwrite these implicitly created global variables? I thought
you wanted to have the cake and eat it too :-P

I've added an improved solution to DWR (checks that the variable we override
actually corresponds to an id in the DOM) and you can try it out here:
http://ci.directwebremoting.org/bamboo/browse/DWRTRUNK-ALL-587/artifact/JOB1
/dwr.jar/dwr.jar
It will be part of DWR 3.0 that we will release the coming weeks.

Best regards
Mike

Ramzi wrote:

> We are currently upgrading from DWR2 to DWR3.
>
> We could change the IDs, but in the interest of making the
> code backwards compatible, I thought I would bring this issue
> to your attention.
>
> Ramzi
>
> -----Original Message-----
> From: Mike Wilson [mailto:[hidden email]]
> Sent: Monday, April 27, 2015 10:59 AM
> To: [hidden email]
> Subject: [dwr-users] Re: Script-tag name conflicts
>
> Just so I understand what you are showing here:
> - you are adding id:s on script tags yourselves, right?
> - the problem goes away if you remove these id:s, right?
> - why do you need these id:s?
>
> Best regards
> Mike Wilson
>
> Ramzi wrote:
> > Hello,
> >
> > Please let me know if this issue is something that can be
> addressed on
> > your end rather than ours.
> >
> > In chrome, when we are debugging,  our project does not minify and
> > concatenate the JS files.  The result is that we get script tags in
> > the DOM with the same "id" attributes as the serverside
> java classes
> > that we are loading- thus making it easier to lookup files for
> > debugging.
> >
> > The problem is that when the DWR client stubs get generated
> each stub
> > calls the dwr.engine._getObject function which checks the
> global scope
> > for remoted classes.  In chrome, however, the window object
> contains
> > references to all script tags loaded and this causes a namespace
> > conflict.  For example for:
> >
> > dwr.engine._global['MethodName']
> >
> > returns
> >
> > <script id="MethodName" type="text/javascript" src="path"></script>
> >
> > and hence the check for undefined fails and the object
> never gets set.
> >
> > To elaborate, the fix I wrote to address this is provided
> in the first
> > conditional below:
> >
> >   dwr.engine._getObject = function(prop) {
> >     //return undefined;
> >     if(dwr.engine._global[prop] &&
> dwr.engine._global[prop].tagName &&
> > dwr.engine._global[prop].tagName === "SCRIPT") return undefined;
> >     var parts = prop.split(".");
> >     var value;
> >     var scope = dwr.engine._global;
> >     while(parts.length > 0) {
> >       var currprop = parts.shift();
> >       value = scope[currprop];
> >       if (parts.length > 0 && value == null) return undefined;
> >       scope = value;
> >     }
> >     return value;
> >   };
> >
> > Thanks very much for your help.
> >
> > Regards,
> > Ramzi
>