Что такое поиск в netbean?

Question

Мне трудно это понять.По сути, этот поисковый API используется для сохранения слабосвязанной межмодульной природы.Таким образом, по сути, модули поставщика услуг и потребителя могут взаимодействовать друг с другом, используя Lookup API, правильно?

Но чего я не понимаю, так это:

является ли поиск похожим на сумку, полную объектов для этого класса?Кто-нибудь может привести более простую аналогию?

Итак, зависимости созданы, и вы правильно реализуете LookupListener в сервисе consumer ?Очевидно, что потребитель зависит от поставщика.

Тогда какова реализация прослушивания LookupListener ?Это собственный поиск?Итак, если есть карта класса другого модуля, она будет сохранена как объект внутри Lookup реализации LookupListener ?

Таким образом, lookup - это что-то вроде пакета, который может хранить классы другого модуля и его методы?

Является ли это правильным процессом определения выбора?

1. в TopComponent (view) вы реализуете прослушиватель поиска и прослушиватель действий.
2. вы создаете новый объект (из другого модуля)
3. associateLookup(Lookups.singleton(fff)); опять же, путаница с этой строкой:что такое associateLookup() что именно вы делаете?
4. result = Utilities.actionsGlobalContext().lookupResult(Browser1.class); что делает эта строка?каков результат?содержит ли он класс Browser1 (из другого модуля)?

5. result.addLookupListener (this);Зачем вам добавлять слушателя к результату?и что мы слушаем и почему в верхнем компоненте?

6. Сделано?

И, наконец, чтобы еще больше запутать меня, как Node API входит в pla7y?

Answer 1

Есть хорошее обсуждение API поиска платформы NetBeans.

Answer 2

Вы можете думать о поиске как о базовом инструменте, который поддерживает принцип слабого сцепления с высокой когезией.

По сути, у вас есть API в beverage-api модуль:

public interface Beverage {
   ...
}

Затем другой модуль beers который зависит от beverage-api:

@ServiceProvider(service = Beverage.class)
public class SomeBeer implements Beverage {
   ...
}

в другом модуле, который также зависит от beverage-api вы можете написать волшебную формулу:

Collection list = Lookup.getDefault().lookupAll(Beverage.class);

который предоставит вам список всех поставщиков напитков в округе без объявления точной зависимости от конкретного класса или наличия зависимости от этого модуля.Это здорово, ваш код не зависит от конкретной реализации, достаточно указать эти модули в пути к классу, и они "автоматически волшебным образом" загрузятся в ваше приложение.

associateLookup(Lookups.singleton(fff)); опять же, путаница с этой строкой:что именно делает associateLookup() ?

Да, это сбивает с толку.По сути, вы вручную добавляете какой-либо объект в систему поиска.

result = Utilities.actionsGlobalContext().lookupResult(Beverage.class);

Utilities.actionsGlobalContext() связан с выбранным в данный момент (активным) TopCompoment.Он вернет экземпляр Beverage.class если он существует в активном компоненте.Если вам нужны все экземпляры данного класса, вы должны использовать lookupAll().

result.addLookupListener(this); Зачем вам добавлять слушателя к результату?

Чтобы получать уведомления об изменениях.Когда пользователь выбирает какой-либо Beverages объекты, которые он запускает LookupListener метод:

void resultChanged(LookupEvent ev);

и result.allInstances(); вернет, какие экземпляры были выбраны.