jQuery Forum

Hi Scott,

Thanks for the quick reply. Yes, I had problems. First, I tried to extend the original solution as much as I could, but then I hit the wall -- the menu is isolated from the parent object (so menu has no way to access the autocomplete object), that was one thing.

I was solving it (not sure if correctly) by menu's method:

getAutocomplete: function() {
        cb = this.option('mainapp') // cb is menu instance
        return cb.call(this.element[0]);
    },

I had to add the mainapp method to the menu instantioan, that simply returned the the autocomplete instance (which is visible to the method, because menu is created in _create() of the autocomplete)

The second thing might be the menu implementation, which I was hacking a bit more - (I am not at all the js pro and jQuery is new to me)

Basically, I would need to instruct certain autocomplete instance to use different menu widget. As far as I can see, there isn't way in the autocomplete to tell so (unless one overrides the whole _create() for the autocomplete widget). But I admit, my lack of jQuery understanding, maybe there is a way to override the $.widget("ui.menu",...) implementation?

Hi Scott,

The change would be almost enough for everything, I have just re-implemented it following your direction like:

1. this.menu = this._createMenu()
               .addClass( "ui-autocomplete" )
               .appendTo( "body", doc )
               .zIndex( this.element.zIndex() + 1 )
               // workaround for jQuery bug #5781 http://dev.jquery.com/ticket/5781
               .css({ top: 0, left: 0 })
               .hide()
               .data( "menu" );
   

then:

1. _createMenu: function() {
2.       self = this;
3.       return $( "<ul></ul>" )
4.       .menu({
5.             focus: function(event, ui) {
   
6.                   ....
7.       })
8. },
   

Having this, one can extend the existing menu by just overriding the _createMenu() method -- I could add the special functions to it

Then, the last thing needed, is to deal with small discrepancy in the close method:

1. close: function( event ) {
           clearTimeout( this.closing );
           if ( this.menu.element.is(":visible") ) {
               if (this._trigger( "close", event ) !== false) {
                   this.menu.element.hide();
                   this.menu.deactivate();
               }
           }
       },
   

The only difference, with respect to the original implementation is the !== false check -- I believe this change fits well with the other triggers, like focus or select, that also return a value if some action should be taken. The close option was not sensitive to it.

If these changes are in place, I could add the other things by extension to the default menu behaviour.
What do you think?

Actually, it is closing automatically, staying open only if false is returned - so this change should not break any existing behaviour.

As for the explanation -- if there is a special implementation, like in my case, the menu opens and displays the 2nd level of autocomplete - but because the click triggered the select and close events, the menu is closed and there is no other place to prevent that from happening.

Also, the close is now kind of similar to the focus and select events where user can choose to return 'false' and prevent action from happening; there also it must be false, I would propose the same for the close event

Hi Scott,

I agree that select event is crucial, but close is also caused by other events - like blur.autocomplete - at least in my case (and possibly from other implementations where autocomplete is not a simple block), it is not possible to catch the event and prevent it when user wants to do something special, like display 2nd level data (it would be possible, if everything was contained in the menu <li> - yet, that is not a solution because for nested items, like the multi-level autocomplete, one would have to detect which of the items was selected - and certain areas have different behaviour - like 'show more' vs. 'select this')

to be clearer:
 <li> higgs #1
    <li> higgs-boson</li>  #2
    <p> show more </p> #3
 </li>

clicking on #2 would (also) trigger #1 selected (if I am not mistaken) and clicking on #3 as well, but #3 should not select the item, but request more data and display more below #2.

Doing it with select, one would have to somehow track what is contained in what, which looks scary to me. But if one can control the menu behavioiur, then I think it would become very easy (and simple, with possibly less problems). Having this layout

 <li> higgs #1</li>
    <li class='nd-level'> higgs-boson</li>  #2
    <p> show more </p> #3

I've put together a prototype based on your video. It doesn't override or prevent any of the existing events.

No problem. As I said, we're really interested in seeing these types of extensions being built. We want to make sure that it's not only possible, but that it can be done without any ugly hacks.