Hi, No, Monday is not late. We can implement it either way - just a note; in tables, searching and sorting is disjunct, we do them independently. But we can implement "sortbysearch" on a single field, and this is what I'm doing.
For typeaheads, I have a prototype working doing this client-side. But if this sort of behaviour is desired in the table pages, too, then it's worth implementing it server-side as a special type of search. One more question - is it ok if I trigger the typeahead when the user input reaches 2 characters in length ? Right now it starts on the first character, but I think the results of searching on one character are too wide - it matches everything ! Cheers, Alex On Thu, Jul 9, 2015 at 10:37 AM, Barros Pena, Belen < [email protected]> wrote: > > > On 09/07/2015 09:46, "Damian, Alexandru" <[email protected]> > wrote: > > >Hi, > > > > > >I've started working on: > > > > > >https://bugzilla.yoctoproject.org/show_bug.cgi?id=7152 > > Ah, great: thanks for taking this on, Alex. > > > > >I wonder if the behaviour described is to happen only in the typeaheads, > >or if it would also apply to the search in tables. > > > > > >Case at hand - in Project compatible layers, when you search "open", do > >you expect to see "openembedded-core" at the top of the list, before the > >layer names starting with "meta" ? Currently, it is at > > the bottom of the search results, because "o" is after "m" in > >lexicographic order. > > Refining the search behaviour would make me really happy, but I am not > sure we can simply transpose the logic from the typeaheads to the tables. > The reason is that search matching in the typeaheads should be done only > against the 'name' (layer name, recipe name or machine name) and the layer > name (so that I can search for a layer name and get a list of for example > machines provided by that layer. This seems to be working at the moment by > the way, and I think it's quite nice). > > But in the tables we match against other fields too, most significantly > the description, which is useful because it allows users to type "natural > language" queries like "small image" and get results. If a search > query > matches against something in a description, I am not sure what the correct > sorting would be. There is a also a potential conflict in the tables > between the sorting applied and any custom sorting we use for search > results. > > So the answer is that it's worth putting some time into thinking this > through. I am going to ask Tiago if he could look at it and come up with a > design proposal by Monday EOD. Would that work? Or is it too late? It's a > holiday in Brazil today, so I know he can only start looking at this > tomorrow. > > Cheers > > Belén > > > > > > >Cheers, > >Alex > > > > > >-- > >Alex Damian > >Yocto Project > > > >SSG / OTC > > > > > > > > -- Alex Damian Yocto Project SSG / OTC
-- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
