2012-06-12 3 views
0

Я считаю, что ралли-паук является определенно полезным компонентом. Однако я не вижу никакого поля конфигурации, которое позволило бы мне запретить пользователям создавать новые теги при сохранении функциональности поиска. Есть ли такая конфигурация? Или это необходимый компромисс между функциональностью?Rally App SDK 2.0: создайте доступный для поиска, но не редактируемый rallytagpicker

ответ

3

лучшее решение, чем мой предыдущий хак:

Ext.create('Ext.Container', { 
    items: [{ 
     xtype: 'rallymultiobjectpicker', 
     modelType: 'tag' 
    }], 
    renderTo: Ext.getBody().dom 
}); 

или

Ext.create('Rally.ui.picker.MultiObjectPicker', { 
    modelType: 'tag' 
}); 

Это поможет вам для поиска сборщика тегов без возможности добавления.

+0

Отлично! Конечно, имеет смысл использовать компонент, специально созданный для тегов. Я могу использовать это над rallytagpicker + hack, так как на этом конкретном компоненте есть уведомление/подсказка, в котором говорится: «Введите, чтобы добавить тег». Можно ли скрыть это? – user1417835

+0

Я нашел ответ на мой вопрос выше.^ Вам нужно будет указать listCfg, например: --- listCfg: {emptyText: ''} Я не уверен, что идея о том, что он позволяет вам напрямую вводить HTML, как это было сделано для представления этого уведомления, может вызвать какие-либо проблемы ... Однако, чтобы это было ясно, это, вероятно, лучший путь, чем попытка взломать rallytagpicker, поскольку этот компонент фактически расширяет раллимультиплексор. Я также обнаружил, что rallymultiobjectpicker загружается быстрее. – user1417835

1

Я не думаю, что система разрешений в это время различает назначение тегов и создание тегов.

+0

Я не совсем уверен, что вы подразумеваете под назначением против творения. Я хочу, чтобы это поле было доступно для поиска, но не было приглашения для создания прямого тега, когда поисковый запрос еще не существует как тег. – user1417835

+0

Я вижу. Тогда нет никакого способа обойти это. Будет ли такой вариант предложен в будущем? Или, может быть, вы можете направить меня на то, чтобы вникать в ее реализацию? – user1417835

0

Вот обходной путь, который работал в TagPicker's code editor in the API, путем переопределения частного метода _showAddNew как пустой функции.

Ext.create('Ext.Container', { 
    items: [{ 
     xtype: 'rallytagpicker', 
     autoExpand: true, 
     toolTipConfig: null, 
     _showAddNew: Ext.emptyFn 
    }], 
    renderTo: Ext.getBody().dom 
}); 

Он также удаляет подсказку инструмента, которая отображается, когда пользователь нажимает на вход поиска.

+0

Спасибо за подсказку! Если бы это было выставлено для модификации, это было бы здорово! Однако это работает только в редакторе кода и недоступно для перезаписи во внешнем коде. Это противоречит настойчивости Чарльза, что было бы трудно подавить эту особенность. Просто должно быть поле конфигурации, которое позволяет установить логическое значение относительно того, должен ли обработчик события вызывать эту функцию. – user1417835

+0

Он также будет работать вне редактора кода, либо создавая его таким же образом (используя имя типа xtype), либо выполняя Ext.create ('Rally.ui.picker.TagPicker, { _showAddNew: Ext.emptyFn, toolTipConfig : null}. –

+1

nOOb commenting. Вот полный комментарий: Он будет работать и вне редактора кода, либо создавая его таким же образом (используя имя xtype), либо делая Ext.create ('Rally.ui.picker .TagPicker, { _showAddNew: Ext.emptyFn, toolTipConfig: null }); Я тот, кто рассказал Чарльзу, было бы сложно, но потом у меня появился второй взгляд. И я согласен, мы могли бы добавить еще один логический в конфиге, которую мы могли проверить перед вызовом _showAddNew. –

Смежные вопросы