DOM and ModelAdmin

Secondly, I'm using it with ModelAdmin. Seems to work ok, except for some javascript behavour that needs modification.

See the attached diff for dataobject_manager.js - this is purely to help upgrade the module to work well with ModelAdmin. It probably breaks nested or multiple instance pages.

Basically, the way the DOM is initiated means that the html is not yet prepared (i think), whereas the Behavior method handles this better. Note that the javascript is a bit mixed up - seems to be mixing prototype and jQuery. Might be worth cleaning this up.

Well that will break nested dataobjectmanager now, so that isn't exactly an air-tight fix.

I avoid the behavior object at all costs and do everything with jQuery. Behavior and Prototype are such hogs, and they slow everything down. In CMSMain, you have to use the Behavior object because it's tied in so closely with the site tree, but in ModelAdmin you shouldn't need it.

I have a feeling your DOM is getting flagged as nested because it's a component of a DataObject, and not a page. I'll have to do some testing.

This is them same error I was having, and it prevents the DataObjectManager being applied to the div. This means that pressing 'add xxxxxx' redirects you to the form, rather than loading it in the popup. Tested XP with IE8, Chrome and FF3.5

This seems to be thrown by:

if(!nested && $(this).attr('id')) {

"this" will refer to the window, which doesn't make sense. I suspect this block of code is supposed to be:

However there is still the problem that when this is executed the DOM (document object model) has not yet been updated. You can prove this by adding "alert(this.length);" to the DataObjectManager function - it will return 0.

This is why I forced using Behavior - it delays execution until the response has been injected into the object model.

Is using the jQuery syntax to run on document ready. If you put alert('hello') in that function, you'll see it happens once the page is loaded.

You were right, the fix was this:

if(!nested && $('.DataObjectManager').length) {

testing for .attr('id') would have effectively done the same thing, but it's a little less clear. I had to figure out why I even had that there. The second condition is to test for the case that a DOM is in the fieldset, but is not displaying because the controller has no ID, e.g. it is displaying the place holder "You may add xxxx when you have saved for the first time..", and therefore there is no DOM holder div.

Is using the jQuery syntax to run on document ready. If you put alert('hello') in that function, you'll see it happens once the page is loaded."

No, This will execute in-line.

Edit: See later posts - the above was incorrect. :)

However, this doesn't fix the problem. $('.DataObjectManager').length still returns 0. This happens whether it is loaded from within the onready handler or not. On your test site (and mine) I still get diverted instead of the popup when clicking "Add xxxxxx".

This will initialize it correctly, after the object model has been updated.

By the way, I don't understand the nested check. Why do you use Behavior.register if it is nested? $('.DataObjectManager') will return the same objects regardless of the check anyway, so the two methods should be functionally identical.