Edgewall Software

Opened 9 years ago

Last modified 9 years ago

#12169 closed enhancement

Replace suggest.js with jQuery autocomplete — at Version 10

Reported by: Ryan J Ollos Owned by: Ryan J Ollos
Priority: normal Milestone: 1.2
Component: version control/changeset view Version:
Severity: normal Keywords: suggest.js anydiff jquery-ui bitesized
Cc: walty8@… Branch:
Release Notes:

Replaced suggest.js with jQuery UI's autocomplete.

API Changes:

The deprecated suggest.js has been removed. jQuery UI's autocomplete widget should be used instead.

Internal Changes:

Description (last modified by Ryan J Ollos)

suggest.js was deprecated in [11081] / #7355, to be replaced with jQuery autocomplete. The only use of suggest.js is:

Concurrently we can look at resolving #8471 and #8429.

Change History (12)

by Peter Suter, 9 years ago

comment:1 by Peter Suter, 9 years ago

Just in case this safes anyone some time:

comment:2 by Ryan J Ollos, 9 years ago

Description: modified (diff)

in reply to:  1 comment:3 by Jun Omae, 9 years ago

Replying to psuter:

At least, three things:

  • We should keep parameter naming for compatibilities (qterm)
  • Use to_json() instead of JSONEncoder.encode
  • It would be good to rename variable elem since the variable is a list of path, e.g. paths

comment:4 by walty <walty8@…>, 9 years ago

Cc: walty8@… added

by walty <walty8@…>, 9 years ago

comment:5 by walty <walty8@…>, 9 years ago

Basically the same patch as psuter, just modified the 3 places mentioned by jomae.

For the query string problem ( termq), there is actually no easy way to do that except providing a source function. The reference is here: SO:10791968.

Last edited 9 years ago by Ryan J Ollos (previous) (diff)

comment:6 by Ryan J Ollos, 9 years ago

Milestone: next-dev-1.1.x1.2
Owner: set to Ryan J Ollos
Status: newassigned

The changes look good to me. I added some minor modification in log:rjollos.git:t12169_suggest_js_replacement. I'll test in additional browsers tomorrow.

comment:7 by Ryan J Ollos, 9 years ago

What are the use cases for keeping compatibility in parameter naming? [5097dc7b/rjollos.git] will keep the server-side API backward compatible. It wouldn't cover the use-case of implementing an IRequestFilter for modifying the xhr request. I'm always in favor of backwards compatibility, but it doesn't seem worthwhile to add a more complex solution unless we have a concrete use case. This change is being made in a major release, so API changes are acceptable even though we want to minimize them.

comment:8 by Jun Omae, 9 years ago

No use-cases for me. However, no way to make sure of that all plugins and users except Trac core don't use q parameter in the AnyDiffModule.

The server-side API backward compatibilities in [5097dc7b/rjollos.git] looks good to me.

comment:9 by Jun Omae, 9 years ago

Another suggestions:

  1. It would be good to use window.location.pathname rather than hard-coded diff url.
    -        $("#anydiff input[name$='_path']").autocomplete({source: "diff"});
    +        $("#anydiff input[name$='_path']").autocomplete({source: window.location.pathname});
    
  2. .encode('utf-8') is redundant since to_json() always returns str instance. In Trac 1.0.x with Python 2.5, to_json() returns str or unicode instance.
    -            content = to_json(paths).encode('utf-8')
    +            content = to_json(paths)
    

comment:10 by Ryan J Ollos, 9 years ago

API Changes: modified (diff)
Release Notes: modified (diff)

suggest.js displays directory entries in bold. I've added similar behavior in rjollos.git:t12169_suggest_js_replacement.1. Overriding _renderItem required that jQuery UI be upgraded (#11019). The changes will require much more extensive testing than I've done so far.

Note: See TracTickets for help on using tickets.