Conflict with ajax library

Poster: matt_
Dated: Monday September 12 2005 - 17:50:40 BST

We recently started using your menus, version 5.729, and all was going well until I tried to integrate it with the Prototype ajax library http://prototype.conio.net/ and Prototype no longer works because its most basic function is $(). I realized you make heavy use of the dollar sign in your obfuscated code. I tried doing a find/replace in your code to change the dollar signs to something else, but no dice. Is there anything that I can do? I don't want to give either of these components up.
Thanks.

Poster: Ruth
Dated: Saturday September 17 2005 - 6:05:47 BST

Hi Matt,

I was hoping someone would answer this. I believe you'll have to contact Milonic about this issue. It's not something we can really do on a forum, especially since you're not supposed to modify the program files. I'm sure they can work a solution for you.

Ruth

AJAX is getting more pouplar

Poster: rav4ski
Dated: Thursday September 29 2005 - 13:59:05 BST

Hi,

My company also has a corp. license of Milonic. (Thanks to me, of course. ). We are using it and very satisfied with the product and support.

Currently, a huge re-design is going on and we are looking forward to extend the usage of Milonic menu. In addition, I think the AJAX is getting so popular and it will be part of the solutions that we are looking for as well.

I will start testing the AJAX in a couple of weeks. I hope the Milonic and AJAX can co-exist w/o conflicting to each others since both of them are considered as the most sophisticated usage of the Java Scripts.

Poster: Andy
Dated: Thursday September 29 2005 - 14:40:02 BST

The menu should work fine with AJAX but will depend on the implementation.

If there are any problems please let me know and I'll do what I can.

With regard to http://prototype.conio.net/ I'm going to need to see this problem first hand, if you can create a demo using both the menu and the http://prototype.conio.net/ AJAX script, I'll find the conflict and change it.

Hope this helps,
Andy

Poster: dpetrie
Dated: Monday October 10 2005 - 21:03:54 BST

I can confirm having issues with Milonic menu and prototype as well. The errors were coming from the ${} function. I am going to try and put together a demo that you can trouble-shoot. I would encourge others to do the same.

Prototype is a very powerful scripting library that, along with script.aculo.us, is gaining huge popularity. Making Milonic compatible would give developers a complete arsenal. I plan to use both once an update is implemented.

Poster: Andy
Dated: Monday October 10 2005 - 21:31:04 BST



We'll do what we can - let me know as soon as the problem is visible.

Who so you think should back down on the variable name though Us or Them?

--- Andy

Poster: dpetrie
Dated: Monday October 10 2005 - 21:40:45 BST

I submitted a ticket (#6202) moments ago with an example of the issue. Prototype is becoming a very popular scripting library for web developers and I doubt if they would be receptive to such an implementation change at this point.

Hopefully a change on this end would not be that intrusive.

Poster: jball
Dated: Tuesday October 11 2005 - 18:19:52 BST

The prototype library is a very popular standard for implementing ajax which comes from ruby on rails. One of their core overloads for an element accessor is function $(). It would be unreasonable for the prototype makers to change this as it is an external function and used by many sites, whereas the obfuscation of this menu library is purely internal and should not effect any existing implementations.

Personally I evaluated the Milonic menu system for my company recently and noticed its incompatability with prototype; hence I moved on to find another menu system that was compatable. Today by chance I found this forum posting and I am very interested in a speedy resolution to this issue as I would very much like to purchase and implement this menu system with my ajax library.

In terms of recreating the problem, simply add (this is by hand so there may be a typo)



to an existing menu implementation

Poster: Andy
Dated: Tuesday October 11 2005 - 19:02:49 BST

Hi All,

The Pre Release version of the menu found at http://www.milonic.com/menuvinfo.php contains a fix for the rouge variable.

This version will become final release within the next few days.

Please let me know if you find any problems and I'll get right onto it

Hope this helps
Andy

Poster: dpetrie
Dated: Tuesday October 11 2005 - 19:05:30 BST

Thank you Andy.

I will try this immediately and provide feedback as soon as possible! I am every excited about having these two products coexist.

Again, thanks.

Poster: dpetrie
Dated: Tuesday October 11 2005 - 19:47:15 BST

Andy I have done some preliminary testing and everything seems to be working fine using the pre-release you provided. I tested some of the prototype/script.aculo.us functionality with no incident.

I will report any issues as they come up.

Thank you.

Poster: jball
Dated: Tuesday October 11 2005 - 23:21:38 BST

Great! I'll try as soon as I get home tonight as well and let you guys know.

Poster: jball
Dated: Thursday October 13 2005 - 0:06:06 BST

I downloaded the prerelease version and it works fine with prototype. Thanks for the quick response, you'll get getting a cheque soon

Poster: shiroh
Dated: Tuesday January 10 2006 - 23:15:36 GMT

It looks like there is another conflict. The new prototype library (1.4) includes the $H() function for emulating Hash elements which conflicts with functions in the mmenudom.js file.

Same Issue

Poster: Schekky
Dated: Thursday February 2 2006 - 16:17:58 GMT

I am encountering the same issue with prototype.js and the Milonic menu not playing nice together. Are there any plans to fix this? The menu is great, but part of the system that I am building requires AJAX.

Poster: Andy
Dated: Monday February 13 2006 - 15:53:39 GMT

Hi All,

I have removed the variable $H from the menu.

I'm not sure how long we can go without the menu and Prototype conflicting again.

I'm also not sure why we should change our variable names too. Can't they meet us half way and change some of their variables? We used $H first so why should we change?

If somebody can contact them and see if we can try and eliminate future conflicts that would be great.

Cheers,
Andy

Poster: undetected
Dated: Monday March 20 2006 - 23:43:26 GMT



I think the answer is simple, though not easy: start using namespaces. Both Milonic and Prototype are guilty of modifying the global namespace, of course, but since you don't control the Prototype code, maybe you can do something about it with the Milonic code.

This way you'd avoid any conflict with any other Javascript library (or even any existing Javascript code a future customer could have).

Collision w/Prototype 1.5.0-rc0 and Milonic

Poster: kmcgrail
Dated: Thursday May 25 2006 - 22:08:55 BST

Using Prototype 1.5.0-rc0 and Milonic Version 5.747, I'm seeing another collision between the two libraries.

Specifically Form.Element.Serializers[method] is not a function at line 1507 in prototype-1.5.0-rc0.js

Subsequent mouse overs on the blank menu give an error of Element has no properties at Line 1506 in prototype-1.5.0-rc0.js

getValue: function(element) {
element = $(element);
var method = element.tagName.toLowerCase(); <-- 1506
var parameter = Form.Element.Serializers[method](element); <-- 1507

if (parameter)
return parameter[1];
}

Poster: Andy
Dated: Wednesday May 31 2006 - 19:04:32 BST

After looking at the code I think it's unlikely to be related to our menu, there is nothing in there that points to anything we have done.

I'm getting the impression that the guys from prototype are doing this on purpose now.

I;m also getting reluctant to change our code every time they release a fix. Milonic was around LONG before AJAX was invented so who really is to blame for all of this? - It's debatable.

Can I ask you to take it up with them, this is not a "Cop Out" just a request to see if they can cut us some slack, if not come back to us and we'll see what we can do.

Conflict with Prototype & Milonic

Poster: kmcgrail
Dated: Wednesday May 31 2006 - 21:34:38 BST



The issue seems to be boiling down to "Why should Milonic change and not Ajax/prototype"? I hear you and I give a high amount of credence to this complaint. I'm pretty sure they AREN'T breaking it on purpose but I know it must feel that way.

The 3 answer(s) I have developed after researching and pondering the issue is that A) IDEAL: both should change to have non-conflicting namespaces or function names , B) REALISTIC?: that Milonic and Prototype should work to minimize these problems going forward and that C) NECESSARY: Milonic should change in the meantime because it's code is proprietary and commercial giving a higher level of response requirements to customer than an open source project.

It's hard for me to open a ticket with Ruby/Prototype because people can't view/edit milonic's code nor really even easily debug it to pinpoint the problem because it is heavily obfuscated. If you can give me some pointers as to what the bug is, I'll happily open a ticket at http://dev.rubyonrails.org/. Though, Andy, I'd suggest that you might have more weight in posting a ticket. NOTE: I have kids, own a business and work with open source a lot so I understand the difficulty of balancing releasing your work and still paying your bills. This is NOT a proprietary / closed source vs. open source debate.

Anyway, I've put up a set of simple test pages to demonstrate the incompatibility:

The index page http://www.thoughtworthy.com/ajax-milon ... index.html has both Prototype and Milonic enabled.

The second page http://www.thoughtworthy.com/ajax-milon ... lonic.html has the <script> call for prototype changed to <disscript>.

The third page http://www.thoughtworthy.com/ajax-milon ... otype.html has the <script> calls for milonic changed to <disscript>.

Regards,
Kevin A. McGrail

Poster: Andy
Dated: Wednesday June 28 2006 - 14:41:27 BST

Having trouble viewing these files, did they get deleted?

Poster: kmcgrail
Dated: Wednesday June 28 2006 - 15:20:10 BST



I moved them to our devel-errors after our private correspondence but I have added a redir so that the files at http://www.thoughtworthy.com/ajax-milonic-error are available once more.

Thanks for looking into this!

Poster: Andy
Dated: Wednesday June 28 2006 - 15:43:53 BST

Just had a closer look and the problem appears to be on line 1507 of prototype-1.5.0.rc0.js

The code is:



There is nothing obvious in the menu that is causing this conflict so I'm at a loss as to why the Serializers function is being deleted. It appears to be fine if the menu is removed but only present if the menu builds.

Sorry I can't help but I must put this down to an issue with the Prototype script.

Poster: Andy
Dated: Wednesday June 28 2006 - 16:25:13 BST

Try the Pre Release now - Think I've found it

Poster: kmcgrail
Dated: Wednesday June 28 2006 - 17:01:34 BST




If you reload the index.html page which has both prototype & milonic enabled and mouse over the place where Home Page is on the milonic menu at the top, you'll notice the error is on 1506 in that instance.

This leads me to believe that perhaps a collision occurs because of a call that is triggering the call to Form.Element.getValue; in prototype.

For example, prototype uses

Milonic uses

Possible that these variables slamming might be the source of the confliction?

Since Milonic is (essentially) closed source, as a customer and programmer, I would suggest any public functions or variables really should be like Function $milonic_F. The use of shorthand variables for a non-API js is likely to always cause headaches. You are probably doing it for obfuscation purposes but doing so is likely to cause Milonic to lose potential customers because prototype is VERY popular.

I know right now as much as I enjoy Milonic, our powers that be will choose to keep Prototype and shelve Milonic if the issue isn't solved. I also think other clients, existing and potential, will do the same. This means less customers for Milonic, pure and simple which is unfortunate because outside of the javascript collisions with prototype, it is a great product that has served us well.

Poster: Ruth
Dated: Wednesday June 28 2006 - 17:40:49 BST

Hi,

Did you try the pre-release as Andy suggested?

Ruth

Poster: Andy
Dated: Wednesday June 28 2006 - 18:15:26 BST

$F has been removed from the menu now.

As Ruth suggests, the Pre Release will probably be OK now.

Cheers,
Andy

Poster: kmcgrail
Dated: Wednesday June 28 2006 - 18:33:39 BST



Apologies to Ruth. I was writing my response during the time that Andy also found the problem and prior to his posting about the pre_release so the chronology is skewed. I was not weighing in on the pre release as yet.

However, Andy's research and mine concur that the collision with $F was the problem. I have tested the v5.752 pre release and happy to report that the problem is resolved as far as I can tell.

http://www.thoughtworthy.com/downloads/ ... rerelease/

We'll sacrifice a few interns to try and appease the prototype gods from doing this again.

Thanks,
KAM

Poster: Andy
Dated: Wednesday June 28 2006 - 18:38:22 BST



Oh, I'm sure she won't mind


From what I can gather the conflicts are all based around the "Dollar Capitol" letter variable names. We use them like that to keep the variable names short and because we assumed nobody else would use this method.

So, in the future we know where to look. It would be fantastic if you could get the guys at Prototype to use variable $pF instead of $F - It's only one extra character and if we guarantee NOT to use this method we should be OK for the future.

Poster: kmcgrail
Dated: Wednesday June 28 2006 - 19:04:57 BST




I think to get $pF implemented for Prototype would be like derailing a freight train because this would change Ruby on Rails as well. Pun intended but as I said, I think that changing an API (or programming language) versus a closed-source program is going to continually come back to the closed-source program. Heck, it took me this long to figure out it was $F collision!

Regards,
KAM

Poster: Andy
Dated: Wednesday June 28 2006 - 19:13:14 BST

Point and pun taken

I'm of the opinion though that the variables are internal to Prototype and so may not affect anything. Although, I'm only guessing and could be completely wrong.

Let's leave it then and see what happens.

Hopefully Prototype will settle down and changes will become less frequent in the future

Poster: kmcgrail
Dated: Wednesday June 28 2006 - 19:36:10 BST



Agree that things should settle down but as an FYI, based on the quite excellent documentation Sergio did at http://www.sergiopereira.com/articles/prototype.js.html I believe these to be external variables for functions.

Regards,
KAM