issue with nested listview using data-filter #5016

Closed
eduardovendruscolo opened this Issue Sep 17, 2012 · 10 comments

Comments

Projects
None yet
4 participants

I have a application with two nested listviews, in another words, i have a listview, and into a

  • tag i have another listview, the issue is the data-filter i put in the external listview, but the jquery mobile render for the nested listviews too, then my application appears several search fields which do the same thing, make filter for principal listview but render tree times. The jQuery Mobile build a data filter field for each list, i try to put data-filter="false" in the nested listview but no works. if the code bellow be executed, will appear tree fields for filter rather than one.

    <script src="http://code.jquery.com/jquery-1.8.1.min.js"></script> <script src="http://code.jquery.com/mobile/1.2.0-rc.1/jquery.mobile-1.2.0-rc.1.min.js"></script>
    <div data-role="page">
        <div data-role="header">
            <h1>Problem nested list views</h1>
        </div>
        <div data-role="content">   
    
            <ul id="external" data-role="listview" data-theme="b" data-filter-placeholder="zua..." data-filter="true">
                <li>
                    <div data-role="collapsible">
                        <h3>first</h3>
                        <p> 1 </p> 
    
                        <ul id="nested" data-role="listview" data-inset="true" data-filter-placeholder="zua..." data-filter="false">
                            <li> <a> 1 nested </a> </li>
                            <li> <a> 2 nested </a> </li>
                            <li> <a> 3 nested </a> </li>
                        </ul>
    
                    </div>
                </li>
                <li>
                    <div data-role="collapsible">
                        <h3>Second</h3>
                        <p> 2 </p> 
    
                        <ul id="nested2" data-role="listview" data-inset="true">
                            <li> <a> 4 nested </a> </li>
                            <li> <a> 5 nested </a> </li>
                        </ul>                       
                    </div>              
                </li>
                <li>
                    <div data-role="collapsible">
                        <h3>Third</h3>
                        <p> 3 </p> 
                    </div>              
                </li>
            </ul>                               
        </div>
    </div>
    
  • Contributor

    robschmuecker commented Sep 17, 2012

    Hi Eduardo,

    This isn't a documented feature and hence you are having issues. I can see that there is an issue with the search filter bar being rendered for each UL it has as a child regardless of whether As for the filtering, the search input will filter on all text within an li and hence in your example you get the first 2 collapsible DIVs returning when you type in "nest" for example. What you could do there is run a custom filterCallback function to return only the collapsible DIVs you want.

    I have tried to provide a working test case on the JSBin that Jasper @ugomobi kindly setup but was unable to get it to override the listview.filter successfully without messing with original core code. What I've ended up doing is a rather hacky solution is to make a "cache" of element ID's which have been parsed to create a search-filter and choose not to re-markup the input if already exists in the "cache".
    Naturally you need to make sure that you give each of your lists which nest others a unique id.

    You can see the file and the changes here https://github.com/robschmuecker/jquery-mobile/compare/fix-5016 I'm not certain that this is the ideal way to deal with this case but have tested and it works fine in IE7+ and Webkit. If this is not something which will work for you I would go down the route of "hiding" the extra search-filters via CSS.

    As you can also see by this JSBin http://jsbin.com/uwaxaj/9/edit it only is affected by lists nested within itself.

    Hope that can help somewhat.

    R.

    Thanks for your attention, and @ugomobi too, i saw the Java Script file altered by you, and understand your way to solve the problem.

    Sorry, this is the first issue if i'm publish here, what your's policy about this issues, you will disponibilize this alteration on jQuery Mobile 1.2.0 oficial release?

    thanks.

    Contributor

    robschmuecker commented Sep 18, 2012

    Hey Eduardo, no need to be sorry!

    Issues happen to all of us! I was just saying that since it wasn't documented it probably hasn't been tested to work before and hence you had issues. I agree with you that it "should" work as you intended as it shouldn't matter what the "children" of a listview are. This is a bug in my opinion and I think it needs to be fixed at a part in the framework a little lower down that my hack but since I'm also fairly new to jQuery Mobile I'm still not 100% where that should be happening ! I think this should/will be fixed by someone, either myself or one of the other great contributors around here and then at some stage it would hopefully be tested and implemented into the framework!

    Good luck!

    R.

    Member

    jaspermdegroot commented Sep 18, 2012

    Looks like the issue is caused by event bubbling. The listview filter plugin is bound to the listviewcreate event.

    Contributor

    toddparker commented Sep 18, 2012

    This is a classic case of the how each option you add makes life exponentially harder. If you have what looks like a single collapsible list but is actually multiple lists, each within a collapsible then the filter is going to be really tricky. If you guys want to try and make this work, I can see if being really useful.

    Contributor

    robschmuecker commented Sep 18, 2012

    Yes I agree this would be great if it could work correctly as other components do within each other. From previous experience using ExtJS it certainly makes for interesting and flexible UI capabilities when all components gel well together but yet can remain totally separate.

    I will investigate further and report back.

    R.

    robschmuecker pushed a commit to robschmuecker/jquery-mobile that referenced this issue Sep 20, 2012

    listview.filter :added a uuid check. Fixes #5016 -listview.filter fir…
    …es create event twice
    
    Listview fires event twice if nested lists are instantiated within the
    "parent" list and hence were adding the searchbar for each contained
    list.
    Contributor

    robschmuecker commented Sep 20, 2012

    Hi All,

    As @ugomobi mentioned there was an event bubbling twice, a "parent" list which had data-filter="true" would receive not only it's own listviewcreate event and hence insert a search bar before it's own list but would also be notified of any listviewcreate of it's children so would prepend another search bar for each child listview.

    I have taken the UUID of the listview to allow the listview.filter to check if it's already present in the dom and hence not re-add itself. This means I have added a new data-attribute in the form of

    .attr( "data-" + $.mobile.ns + "list-id", listview.uuid )

    I'm not 100% certain whether this is the best way but certainly more elegant than my previous solution due to the fact that we are not adding any more overhead into memory but rather checking on-the-fly for the existence of a previous instantiation of the list and hence filter input. I am not sure how if at all possible it could be to prevent the subsequent event bubbling from happening on the listview with nested listviews?

    I have updated the js/listview.filter.js and added a proof-of-concept file to prove it now works with "unlimited" nesting at issues/test-5016.html in my latest commit at robschmuecker/jquery-mobile@50aecba

    please have a look and if you're happy with the fix I can write a test-case before putting a PR together.

    Thanks,

    R.

    Hello..

    in my opinion the change is valid, the filter is not appear twice if filter has been build for a component.

    Thanks.

    Member

    jaspermdegroot commented Feb 19, 2013

    Closing as won't fix. See #5657.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment