Atom Reference Performance Issue

While we can move the logic into server side, we can still do it client side by using a single AJAX call to fetch all atoms. I think it will have less code rewrite.

I had this issue on a site with huge (100+) atom references;
I found the cause not being fetch atoms (which is fast), but the "installation" of CTools buttons, behaviors, etc...
Removing all CTools stuff (including CTools modal frames), I have now a load time < 10 seconds (2" server build time, 4" to 8" client build time, depending on thumbnails being cached or not).

I have no time to build a patch now (and it would probably not be committed...), so I just attached the full module I use.
(I removed the "Edit" button, since the "View" button opens the atom/{sid} page in a new tab)

[Edit : my use case is atom_reference fields as items of scald_gallery atoms : Not sure if nodes are significantly slower than atoms ? ]

I found the patch in #4 worked great but didn't work if I had multiple atom references on one page.

The patch below should fix this.

Patch at #6 works great, but does not apply to current dev — re-rolled

I've made some more updates to the patch today as I also wanted to add support for multi-value fields. Previously there was an issue when the 'add another item' button was clicked.

Hmm, Am i missing something? Or there was never a need for a fetchAtom in there as the image was always added on the server?

Can anyone help reviewing this patch?

Okay, after further tests, it seems that the patch will need some further work.

The atom reference js needs the atoms in the field to be in the Drupal.dnd.Atoms array. (At the moment this is cause of the context override).

However since the fetchAtom is now removed in this patch, that wont happen. Of course if the inserted atom is on the first page of the dnd library then its fine, but otherwise its not.

So the solution could be to create a new function in dnd module that creates data for a specific atom, and then that can be called in scald_dnd_library module and also in the atom reference module, as both depends on the dnd module.
Then we can probably use drupal_add_js to add the items in the atom reference as js settings, and hopefully it will be merged together with the items coming from the library.

The atom reference js needs the atoms in the field to be in the Drupal.dnd.Atoms array.

Can you elaborate on this ?
I can't figure a sequence where atom_reference.js would reference an atom not present in Drupal.dnd.Atoms.

Do you get a js error ? something that just doesn't work ?

Drupal.dnd.Atoms only contains the atoms that are on the first page of the dnd library.

So if you have atoms in the atom reference that is not on the first page of the library, then it wont exist.

I tried to find if those atoms in the atom reference are added in the Drupal.dnd.Atoms somewhere on the server, but could not find it. As the fetchAtom call in JS is removed in this patch, and that causes most of the performance improvement, it wont really be done from js.

If anyone can work on this to finish it, then I could make a new release.

@nagy.balint : Drupal.dnd.Atoms is used only as a temporary (cache) storage for the drag and drop process.

I'm using #8 for 6 months without any flaw.

If you get any error or unexpected behavior, please provide steps to reproduce, etc...

I think i described it well enough in #11 and #13.

If the atom that is referenced in the atom reference is not on the first page of the dnd, then it does not work properly, for example when we enable the context override.