Conflict with ajax library

[Andy]

Having trouble viewing these files, did they get deleted?

[kmcgrail]

Having trouble viewing these files, did they get deleted?

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!

[Andy]

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

The code is:

Code: Select all

var parameter = Form.Element.Serializers[method](element);

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.

[Andy]

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

[kmcgrail]

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

The code is:

Code: Select all

var parameter = Form.Element.Serializers[method](element);

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.

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

Code: Select all

var $F = Form.Element.getValue;

Milonic uses

Code: Select all

function $F(v){if(_d.getElementById)return _d.getElementById(v);

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.

[Ruth]

Hi,

Did you try the pre-release as Andy suggested?

Ruth

[Andy]

$F has been removed from the menu now.

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

Cheers,
Andy

[kmcgrail]

$F has been removed from the menu now.

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

Cheers,
Andy

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

[Andy]

Apologies to Ruth

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.

[kmcgrail]

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.

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

[Andy]

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

[kmcgrail]

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.

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