I am using an UpdatePanel that contains several LinkButtons and a GridView control. The LinkButtons are used to select/deselect all of the checkboxes in a column of my GridView. I am also using a javascript library that implements javascript tooltips. When
the page loads the javascript tooltips work, but after I click the LinkButtons and the GridView is updated the tooltips no longer work. When I remove the ScriptManager and the UpdatePanel from the page and allow the GridView to postback the tooltips work
correctly. I also ran into a similar issue when I was including another javascript library to do dynamic image reflections. When that library was being used paging would not work on the GridView. As soon as I removed the other javascript library the GridView
paging worked. Any ideas on how these conflicts can be resolved so that I can use other javascript libraries alongside Atlas?
It's really hard to say without seeing your code. It kind of looks like your tooltips library is initializing at some point using the ids on the page, but it's not expecting the page to change in a major way after it's initialized. Maybe this tooltip library
needs to be reinitialized after an Atlas update panel has been refreshed?
So I don't think it's a conflict as much as this other library not expecting the kind of stuff Atlas does (Atlas uses namespaces to minimize the chances of conflict). For tooltip, did you look at the popup behavior?
Bertrand
----
This posting is provided "AS IS" with no warranties, and confers no rights.
Thanks for the response. I'm somewhat of a newbie to javascript so I'm not sure how to reinitialize the javascript after the UpdatePanel has been refreshed? What you are saying makes sense though, as the library requires that you put the link to the script
at the bottom of the document. I tried moving the reference to the tooltip script into the ContentTemplate of the UpdatePanel and this resulted in Atlas working correctly at first but then the page goes completely blank and seems to hang. I also diffed the
page source before and after I clicked the LinkButton in the UpdatePanel and the source was identical. Nothing changes between the pages except for checkbox selection. What part of my source would be useful for you to see? It's really just a pretty standard
Gridview inside of an UpdatePanel. The javascript tooltip library that I am using can be found here http://www.walterzorn.com/tooltip/tooltip_e.htm
The new Atlas javscript definetly causing conflicts
I tried using script.aculo.us (http://script.aculo.us) with atlas, and i'm getting javscript errors too...
When i remove the atlas script manager javascript tag:
<script
src="ScriptLibrary/Atlas/Debug/Atlas.js"
type="text/javascript"></script>
Well, you could also say that script.aculo.us is causing conflicts ;). We really can't ensure compatibility with other libraries that act on a very fundamental level (like extending Object and Function). We use namespaces to avoid the risk of collision,
but there's really no way around the fundamental OOP stuff that we do. I think script.aculo.us relies on the prototype library that's similar to our atlasruntime.js and that's probably where the incompatibility really is.
I can see what scenarios would need such compatibility: using ASP.NET with UpdatePanel on the server and a third party library on the client, but I don't think there's a way we can ensure the compatibility with every other library out there.
Bertrand
----
This posting is provided "AS IS" with no warranties, and confers no rights.
"I don't think there's a way we can ensure the compatibility with every other library out there."
That's an extremely unfair statement in response to the original question. Prototype is not just "some library", it's a very popular, well-tested, and well respected library that is the underpinning of virtually all of today's Ajax-like web sites.
It a website doesn't render correctly on IE6, you can't say "Oh there is no way for me to ensure the compatibility with every single browser out there". Sure you can... you test with IE6 because it is the market leader. Prototype is the same way.
I found this thread because I am researching an incompatibility between Prototype (which I use for pretty little animation effects) and ATLAS (which I use for core updatepanel kind of stuff). I think the ASP.NET and Atlas teams really need to take into account
Prototype compatibility.
How do you maintain compatibility between two libraries that essentially extend the *same* objects? Prototype is not a browser, and it's not a standard either. There is no official documentation that I could find, and we just can't look at the source code
for obvious legal reasons. From some of the unofficial documentation that's floating around on the web, I can confirm that it extends the same objects that Atlas is extending, like for example Array.
Asking for compatibility between Atlas and Prototype is like asking for compatibility between ASP and PHP. I don't see that happening. Sorry.
Bertrand
----
This posting is provided "AS IS" with no warranties, and confers no rights.
"and we just can't look at the source code for obvious legal reasons"
I agree that there is no way to maintain compatibility between two JavaScript libraries if you can't look at the source code for one of them, particularly if they both have the same intent (bringing OOP principles to JavaScript 1.5). I withdrawal my request
for Atlas-Prototype compatibility.
However, if it somday becomes legally permissible look through the source (http://dev.rubyonrails.org/browser/spinoffs/prototype/), then I think you'll find it possible -- maybe not a piece of cake but definitely possible -- to avoid incompatibilities.
Also, I feel sorry for you gusy! I've been looking at Atlas.js and AtlasRuntime.js and all the while I thought you were modeling Prototype or Rico or X or one of those frameworks. It's a shame that there has had to be so much "recreating of the wheel".
There's a compelling business case to recreate the wheel when you're dealing with licensed, compiled code. But with a JavaScript framework, your entire source is exposed. Just seems like the perfect opportunity to "stand on the shoulders of giants" instead
of writing a bunch of plumbing for extending Object and Array.
There sure is a lot of duplication of effort here but you should also know that the design decisions we have to put into Atlas are often far-reaching as there are many constraints that may not be initially visible and that may not exist for other frameworks
(like consistency with the .NET framework wherever possible, MSN using our stuff, etc.). So even if it was possible for us to stand on top of things like Prototype, it would probably not fit our needs.
While it may seem a little silly to say that we can't look at the source code whereas it's plain text that's downloaded by the browser, it doesn't matter from a legal standpoint. We just can't look at it, let alone use it. No more than we can use Reflector
on third party .NET libraries to look at their source code. The technical aspect of it does not matter.
I hope this clarifies.
Bertrand
----
This posting is provided "AS IS" with no warranties, and confers no rights.
I'm still having issues with my orginal situation. The javascript file that I'm trying to use can be found at http://ericappel.net/Groupr/scripts/wz_tooltip.js It does not make use of the prototype library or anything else that would cause a conflict as far
as I can tell. Would you be able to look at it and see if anything in it would conflict with Atlas? Again, they co-exist fine until Atlas updates the GridView, however, after the GridView is updated the tooltips stop working. The page source is identical
before and after the update happens (According to firefox anyways).
EricAppel
Member
75 Points
15 Posts
Atlas causing javascript conflicts?
Jan 26, 2006 12:16 AM|LINK
Thanks,
Eric
bleroy
All-Star
15617 Points
2302 Posts
Re: Atlas causing javascript conflicts?
Jan 26, 2006 02:43 AM|LINK
It's really hard to say without seeing your code. It kind of looks like your tooltips library is initializing at some point using the ids on the page, but it's not expecting the page to change in a major way after it's initialized. Maybe this tooltip library needs to be reinitialized after an Atlas update panel has been refreshed?
So I don't think it's a conflict as much as this other library not expecting the kind of stuff Atlas does (Atlas uses namespaces to minimize the chances of conflict). For tooltip, did you look at the popup behavior?
----
This posting is provided "AS IS" with no warranties, and confers no rights.
EricAppel
Member
75 Points
15 Posts
Re: Atlas causing javascript conflicts?
Jan 26, 2006 04:09 AM|LINK
Thanks,
Eric
sarpmg
Member
5 Points
1 Post
Re: Atlas causing javascript conflicts?
Jan 26, 2006 07:45 AM|LINK
Hi,
The new Atlas javscript definetly causing conflicts
I tried using script.aculo.us (http://script.aculo.us) with atlas, and i'm getting javscript errors too...
When i remove the atlas script manager javascript tag:
<script src="ScriptLibrary/Atlas/Debug/Atlas.js" type="text/javascript"></script>
The script.aculo.us scripts just works fine
Software Architect
http://www.feedels.com
bleroy
All-Star
15617 Points
2302 Posts
Re: Atlas causing javascript conflicts?
Jan 26, 2006 07:26 PM|LINK
Well, you could also say that script.aculo.us is causing conflicts ;). We really can't ensure compatibility with other libraries that act on a very fundamental level (like extending Object and Function). We use namespaces to avoid the risk of collision, but there's really no way around the fundamental OOP stuff that we do. I think script.aculo.us relies on the prototype library that's similar to our atlasruntime.js and that's probably where the incompatibility really is.
I can see what scenarios would need such compatibility: using ASP.NET with UpdatePanel on the server and a third party library on the client, but I don't think there's a way we can ensure the compatibility with every other library out there.
----
This posting is provided "AS IS" with no warranties, and confers no rights.
portman
Member
36 Points
9 Posts
Re: Atlas causing javascript conflicts?
Jan 26, 2006 10:13 PM|LINK
That's an extremely unfair statement in response to the original question. Prototype is not just "some library", it's a very popular, well-tested, and well respected library that is the underpinning of virtually all of today's Ajax-like web sites.
It a website doesn't render correctly on IE6, you can't say "Oh there is no way for me to ensure the compatibility with every single browser out there". Sure you can... you test with IE6 because it is the market leader. Prototype is the same way.
I found this thread because I am researching an incompatibility between Prototype (which I use for pretty little animation effects) and ATLAS (which I use for core updatepanel kind of stuff). I think the ASP.NET and Atlas teams really need to take into account Prototype compatibility.
bleroy
All-Star
15617 Points
2302 Posts
Re: Atlas causing javascript conflicts?
Jan 26, 2006 10:35 PM|LINK
How do you maintain compatibility between two libraries that essentially extend the *same* objects? Prototype is not a browser, and it's not a standard either. There is no official documentation that I could find, and we just can't look at the source code for obvious legal reasons. From some of the unofficial documentation that's floating around on the web, I can confirm that it extends the same objects that Atlas is extending, like for example Array.
Asking for compatibility between Atlas and Prototype is like asking for compatibility between ASP and PHP. I don't see that happening. Sorry.
----
This posting is provided "AS IS" with no warranties, and confers no rights.
portman
Member
36 Points
9 Posts
Re: Atlas causing javascript conflicts?
Jan 26, 2006 11:02 PM|LINK
I agree that there is no way to maintain compatibility between two JavaScript libraries if you can't look at the source code for one of them, particularly if they both have the same intent (bringing OOP principles to JavaScript 1.5). I withdrawal my request for Atlas-Prototype compatibility.
However, if it somday becomes legally permissible look through the source (http://dev.rubyonrails.org/browser/spinoffs/prototype/), then I think you'll find it possible -- maybe not a piece of cake but definitely possible -- to avoid incompatibilities.
Also, I feel sorry for you gusy! I've been looking at Atlas.js and AtlasRuntime.js and all the while I thought you were modeling Prototype or Rico or X or one of those frameworks. It's a shame that there has had to be so much "recreating of the wheel".
There's a compelling business case to recreate the wheel when you're dealing with licensed, compiled code. But with a JavaScript framework, your entire source is exposed. Just seems like the perfect opportunity to "stand on the shoulders of giants" instead of writing a bunch of plumbing for extending Object and Array.
bleroy
All-Star
15617 Points
2302 Posts
Re: Atlas causing javascript conflicts?
Jan 26, 2006 11:20 PM|LINK
There sure is a lot of duplication of effort here but you should also know that the design decisions we have to put into Atlas are often far-reaching as there are many constraints that may not be initially visible and that may not exist for other frameworks (like consistency with the .NET framework wherever possible, MSN using our stuff, etc.). So even if it was possible for us to stand on top of things like Prototype, it would probably not fit our needs.
While it may seem a little silly to say that we can't look at the source code whereas it's plain text that's downloaded by the browser, it doesn't matter from a legal standpoint. We just can't look at it, let alone use it. No more than we can use Reflector on third party .NET libraries to look at their source code. The technical aspect of it does not matter.
I hope this clarifies.
----
This posting is provided "AS IS" with no warranties, and confers no rights.
EricAppel
Member
75 Points
15 Posts
Re: Atlas causing javascript conflicts?
Jan 27, 2006 04:05 AM|LINK
Thanks,
Eric