inline_autocomplete demo: how to access dynamically added widgets?

[mpasternak]

Hi,

as you can see, I added the inline_autocomplete demo so I can add more issues for autocomplete inside inlines :-)

I am currently trying to write some code, that uses dependent autocomplete, only in inlines.

To reproduce the problem I am issuing here, first please run the demo and open inlines_autocomplete "add new":
http://localhost:8000/admin/inline_autocomplete/trip/add/

Then, in the browser: launch Firebug or anything you prefer, and then type in console:

>>> $('.autocomplete-light-widget.trip_city_set-0-city').yourlabsWidget()
Object { widget=[1], input=[1], select=[1], więcej...}

As you can see, this works. The widget is found.

Now, please add one more inline, by clicking "Add another Trip_City" link on the page.

Now, let's try to access newly created widget:

>>> $('.autocomplete-light-widget.trip_city_set-1-city').yourlabsWidget()
undefined

... but, when you check all the widgets:

>>> $('.autocomplete-light-widget')

You will see, that there is a with ID id_trip_city_set-1-city-wrapper.

After some time, I found, that:

>>> $('.autocomplete-light-widget.trip_city_set-__prefix__-city')

... will show TWO widgets named like this. One - invisible widget - was copied by django's inlines.js into a new one, which is visible.

Do you have any idea, why the widget retains the original ID (with "prefix" string not updated to an integer)?

Django after copying the invisible row, updates the "prefix" string inside id attributes in inlines.js, line 20 (updateElementIndex).

I suppose I should do something after the widget is copied, like, call a function that will make jQuery to update widget's internal values from id attributes - or something like that. Please help me with this and I will think of creating a sensible patch for that.

[jpic]

Thanks for your extensive description of the problem. I could reproduce it here: http://jsfiddle.net/5uXFS/10/

I asked on #jquery:

14:21 < jpic> hi all, is it possible to bind a callback for when an attribute (id) changes on an element ?
14:21 < quicksilver> no.
14:22 < quicksilver> or at least, not effectively and portably.
14:22 < quicksilver> DOM change events exist but browsers do not support them well.

According to a similar question, we should use the mutation watcher plugin to catch id attribute changes.

We could then do appropriate copies in widget and autocomplete registry - which is still some work.

[jpic]

I just got some tremendous answers from #jquery concerning our problem. Using .data instead of our registry array, should support cloning (and thus, inlines): http://jsfiddle.net/5uXFS/35/

Also, it reduces our codebase for free. So I'm working on that right away B)

[jpic]

The solution in the above commit works for the example: http://localhost:8000/admin/dependant_autocomplete/dummy/

Could you try it and confirm that it works for you too ?

Thanks !

[jpic]

Released in 1.0.13, please re-open the issue if any problem occur.

[mpasternak]

Please reopen this one.

Here's the story:

[jpic]

Ok, it's not perfect ... because it would add a lot of overhead to monitor DOM changes: there is an API but it is barely supported by some browser at this point. The other solution would be to override django's function that creates the inline, which sounds like a very bad idea...

But still, if you're just trying to get dependency between autocompletes in inlines to work, doesn't this example do it ? http://localhost:8000/admin/dependant_autocomplete/dummy/add/

Note that, I had to change the script: http://django-autocomplete-light.readthedocs.org/en/latest/dependant.html#javascript

Tell me what you think of the example, does it work as you expect ?

[jpic]

Also, in your example, this works:

$('#trip_city_set-3 .field-city .autocomplete-light-widget').yourlabsWidget()

[jpic]

I'm going to implement DOMAttrModified event support anyway, hopefully browsers will catch up.

[jpic]

$('#id_trip_city_set-2-city-wrapper').yourlabsWidget() should also work

[jpic]

I did find a really blocking issue thought, seen on remote autocompletes in inlines

updateWidgets() initializes newly created widgets although it shouldn't, and thus custom initialization as described here doesn't work.

A fix was implemented in branch solid_init but I have to make sure that everything still works and figure whether it's backward compatible or not (it might actually be) before I can merge it. Meanwhile, feel free to experiment with it maybe it illustrates your issue.

Until then, documentation for this branch is available

[jpic]

I'm pretty sure this will eliminate whatever problem you have ... please let me know (note that you have to change your custom javascript to use bind('initialize' etc ... see documentation and comment in source code)

[jpic]

Fix released in 1.0.14. Read the CHANGELOG to figure how to benefit from the new initialization pattern. Please reopen if your issue subsists.