295532 - AutoComplete for Name/Value lookup

Status: RESOLVED WORKSFORME

(Toolkit :: Autocomplete, enhancement)

Description

[Paul Tomlin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

It would be useful to have an autocomplete system capable of handling name/value
lookups rather than just plain text values.

My particular example if looking up a MailNewsFolder URI but wishing to display
the 'Label' associated with the path.

Reproducible: Always

Steps to Reproduce:




I'm not sure how to include this in the architecure, but I suspect it would need
some change to the nsIAutoCompleteSession interface.

I'd thought that the nsIAutoCompleteItem.param attribute night be useful, but it
is not easily determined from an nsIAutoCompleteSession which item in the drop
list was selected.

It might be possible to provide the nsIAutoCompleteSession (henceforth known as
ACS) with a handle to the the nsIAutoCompleteItem selected by the user during
the call to ACS.onAutoComplete, but this would require a change to the API.

http://lxr.mozilla.org/seamonkey/source/xpfe/components/autocomplete/resources/content/autocomplete.xml#559
http://lxr.mozilla.org/seamonkey/source/xpfe/components/autocomplete/resources/content/autocomplete.xml#753

I believe that the ability to use an autocomplete system to lookup a 'value' via
a  'name' has greater potential than that which I currently conceive, but I'm
unsure of the mechanism to get changes to the core of moz to achieve this.

For point of reference of an application to use this, please see Quick File for
Thunderbird.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

FYI, this is for QuickFile use.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Brian, are you the toolkit autocomplete guy?

Comment 3

[Paul Tomlin]

I've made a short blog entry regarding this which might add some understanding.
http://www.paultomlin.com/2005/05/26/enhancing-mozilla-autocomplete/

The pertinant bits are:
A few times in the past I have tried to coax the autocomplete code in
Thunderbird show the user one value and return another to the extension, mainly
so I can show the user the folder label (nsIMsgFolder.name) but use the location
(nsIMsgFolder.URI) for processing.

I’ve never been successful in this, at least not in a way that is extendable
which would allow the creation of something like
@mozilla.org/autocompleteSession;1?type=mailnewsfolders.

Personally, I think I’d like to see the hidden value, the URI in my case, appear
as an attribute of the <textbox /> once an autocomplete occurs.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Paul, sorry for the delay in getting back to you on this; your proposal seems
like a good idea to me.

As you've pointed out in your blog, the best thing to do is to port the mailnews
autocomplete widget to toolkit and then fix the issue there, but that is likely
to be signifcantly more work.  If you're interested in doing that, I'd be more
than willing to support you with advice, contacts, patch reviews as appropriate,
and driving the code into the Mozilla CVS tree.

However, if that's something you can't commit your time to, but you are still
interested in working on a patch to make this proposed change in the old xpfe
code, I'd be happy to support you in that endeavor as well.

It seems to me that adding a displayName attribute to the result interface is
perhaps what is called for here.  I'm not sure whether that really fulfills this
or not, though:

> I believe that the ability to use an autocomplete system to lookup a 'value' 
> via a 'name' has greater potential than that which I currently conceive

Does it?

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #4)
> 
> port the mailnews autocomplete widget to toolkit

What I really meant by the above, is "make mailnews use the new toolkit
autocomplete widget".

Comment 6

[Paul Tomlin]

Unfortunately I'm really stretched on other work for the next few months so I'll
not be able to put this together. I'll keep tabs on it via the bugzilla mails
and come back to it when I have a chance later if it's still relevent.

Comment 7

[Paul Tomlin]

(In reply to comment #4)
> It seems to me that adding a displayName attribute to the result interface is
> perhaps what is called for here.  I'm not sure whether that really fulfills this
> or not, though:

I've just a had a little look at this, checked-out the xpfe/components/autocomplete CVS HEAD and started to naively add a displayName attribute to nsIAutoCompleteItem. It was only when I got into the autocomplete.xml that it dawned on me that a displayName isn't going to easily work here. It would be far simpler to add a 'dataValue' attribute, rather than trying to change all the setValue etc.

Then, a few hours later, I discover this:

http://lxr.mozilla.org/seamonkey/source/xpfe/components/autocomplete/resources/content/autocomplete.xml#1613

Presumably I could use the 'param' property of the nsIAutoCompleteItem to store an nsISupportsString and use it here, though I'm sure that's not the intended usage of 'param' and equally unsure it's the intended use of getOverrideValue.

Comment 8

[Wayne Mery (:wsmwk)]

Is this still a limitation in the current autocomplete

Comment 9

[Magnus Melin [:mkmelin]]

I don't think so, sounds a bit like what bug 754265 did, if I understand it correctly.