[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mylyn-integrators] single-select with many options
|
On Thu, Nov 12, 2009 at 12:28 PM, Larry Edelstein
<ledelstein@xxxxxxxxxxxxxx> wrote:
> How can I support a single-select field in my task that has many, many
> options, way too many to put in a drop-down list? It’s unfortunate that
> this field has so many possibilities, but there’s nothing I can do about
> it. I need the user to be able to select among them. I’ve considered
> supplying a way to hide some of them, but it’s not optimal.
You could consider adapting the version picker that was introduced for
JIRA and Bugzilla in Mylyn 3.3:
http://www.eclipse.org/mylyn/new/#jira. It supports filtering the list
of options. It's currently intended for multi-select fields but it
should be fairly trivial to limit it to single select.
> My best idea is to let the user type the label of the option she wants, and
> provide content assistance so that as she types, the possibilities are
> narrowed, according to that attribute’s options. I’m open to other
> suggestions.
We have sometimes used content assist in combination with a drop-down
since content assist can be more difficult to discover.
> I’d like to use the TextAttributeEditor and decorate it with a content
> assist, when appropriate. It looked at first like the right way to do that
> was to subclass AttributeEditorToolkit, but I can’t do that – the
> constructor has package scope. Pretty useless, then,
> AbstractTaskEditorPage’s non-final, public getAttributeEditorToolkit()
> method, since there’s nothing useful I can do when I override it – I can’t
> create an instance of any other class, and the only meaningful method to
> call – adapt(AbstractAttributeEditor) – can’t be made to do anything new.
The original intention was to make it AttributeEditorToolkit
extensible but it's API and implementation turned out to be too
cumbersome to extend. The compromise was to make the constructor
package private to leave room to fix this in the future.
My sense is that it would be much better to have
AttributeEditorToolkit provide services such as spell checking and
content assist which could be accessed by attribute editors as needed
instead of encapsulating the implementation for applying these
services in the toolkit.
> Seems like the best thing to do is subclass AttributeEditorFactory, look for
> my attribute – I’ll give it a new type, probably – and decorate it myself
> with content assist then.
Yes, that is currently the recommended way to provide a custom UI for
editing of attributes.
Steffen
--
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com
