I must have misunderstood what th0fu said about the implementation of ‘htmlResponse’ …

In order for JavaScript instructions from RJS files kicked off automatically by Rails to be executed properly, I found it was necessary to set ‘htmlResponse: false’. When set to true, the script would be rendered in the modified element (wrong!!), and also executed (altering the other elements on the page properly). Set to false, everything works as it did before in IPE, and finally also allows for execution of scripts after editing is finished in an IPCE.

This has been a very confusing process for me. Thus far, Rails has only been 50% effective or less at hiding the complexity and fragility of JS. But keep up the good work!

I use the "value" option!

I usually find it necessary to update other interface elements when a dropdown list is changed, so I hope there will be support for doing so.

Thank you to everyone who has worked on this!

With regard to demos: please demonstrate the ‘paramName’ and ‘htmlResponse’ functionality — I can find no evidence that it functions as advertised.

I’m using prototype 1.5.1.1 and the very newest controls.js w/ Christophe’s changes. I am not certain whether there are other (undocumented) dependencies on other elements of script.aculo.us 1.7.1b3 … If so, it’d be nice to know that.

As it stands now, IPCE ignores "paramName" and neither it nor the basic IPE (text field) will allow execution of JS sent back to the browser (say, to update other fields on the page). Previously (yesterday, before I upgraded), the IPE would allow JS to execute, but the IPCE would not. I have now -lost- functionality as a result of upgrading.

According to this post, I expected that JS would be executed as if I had set ‘evalScripts’ even without explicitly setting it, since what you say is that it is ‘true’ by default.

If I could find any documentation about how these mysterious features are supposed to work, that would be excellent. If anyone knows of any, please tell me!

Thanks in advance!

The evalScripts option is NOT supported anymore.

If you expect a pure-JS response (as RJS would provide), set htmlResponse: false, and that’s it: because Ajax.Request is used internally, it’ll auto-eval JS-typed responses (i.e. HTTP responses featuring a JS MIME type, see http://prototypejs.org/api/ajax/request for details).

Also, do note that the latest controls.js assumes you’re using the latest trunk, which means the prototype.js version in its lib/ directory (which I believe is more recent than 1.5.1.1, but I might be wrong).

staticnullvoid: the dev space you’re referring to is huge and a hodge-podge of stuff ranging from despicable to excellent. Prototype will put up a 3rd-party lib page that will be carefully screened and monitored. Af for Scripty, every other developer writes some stuff he/she thinks is worthy of attention, but then who can say whether it’s great stuff or absolute crap? Still, Scripty’s current site is a wiki, indeed, so anyone can tweak it: if you’re so enclined, go ahead!

Now – while I try the work with the new controls.js I’ve got some errors with InternetExplorer and the CollectionEditor. Looks like there are JS-Errors while dynamicalyy building the option-list for the edit-field.

Is the InPlaceCollectionEditor working for you in InternetExplorer?

Micha

Prototype recommends using a Hash for Ajax.[Request/Updater] calls.

I think that could be easily done with few changes like:

Rewrite the default callback:
callback: function(form,value) {
return Form.serialize(form, true);
}

Lines like 709:
params = (params ? params + ‘&’ : ‘?’) + ‘editorId=’ + this.element.id;

… should be:
params.editorId = this.element.id;

Which leads to also support a much needed ‘parameters’ option for the IPE. You just need to rewrite 708-710 from controls.js

var params = $H(this.options.callback(form, value));
params.editorId = this.element.id;
params.merge(this.options.parameters);

But, just a suggestion.