Статьи

Повторное использование подключаемых модулей NetBeans в автономных приложениях и в среде IDE


Я просто провел некоторое время по телефону с
Jaspersoft . У них есть интересный пример использования NetBeans: они оба предоставляют
плагин NetBeans и автономный инструмент конструктора iReport, основанный на
платформе NetBeans . Это в высшей степени выполнимо, но я не думаю, что было много разговоров о советах и ​​хитростях для этого. Вот некоторые:

  • Отдельная регистрация пользовательского интерфейса от кода . Среда IDE NetBeans делает это с модулем основного пользовательского интерфейса. По сути, вам понадобится другой набор меню и панелей инструментов в автономном приложении. Вероятно, многие действия будут одинаковыми в любом месте. Так что просто поместите код действия в один модуль, который зависит от того, что ему нужно вызвать; поместите фактическую регистрацию этого кода в файл слоя другого модуля, который зависит от того, кто выполняет действия. Затем подготовьте одну версию этого модуля для IDE, а другую — для автономного приложения.
  • Абстрактные зависимости от модулей IDE. Например, мастер создания отчетов в IDE должен позволять пользователю выбирать классы из текущего проекта. Автономный дизайнер отчетов даже не имеет концепции проектов, а Project API там нет — но пользователь должен иметь возможность выбирать некоторые файлы. Решение этой проблемы может быть таким же простым, как создание модуля API с таким интерфейсом, как
    public interface FileChooserPanelProvider {
    public JComponent getComponent();
    public Iterable<File> getSelectedFiles();
    public void addChangeListener(ChangeListener cl);
    public void removeChangeListener(ChangeListener cl);
    }

    В версии IDE есть модуль, который будет реализовывать этот интерфейс и помещать его в поиск по умолчанию . Эта реализация будет использовать Projects API. В автономной версии другой модуль делает то же самое и просто предоставляет средство выбора файлов или подобное. Пуф! Зависимость нарушена. Мастер нового отчета вызовет

    Lookup.getDefault().lookup(FileChooserPanelProvider.class)

    и получить экземпляр, внедренный любым присутствующим модулем.

  • Если вашему редактору нужно много меню, добавляйте / удаляйте на лету — сейчас многие эксперты по пользовательскому интерфейсу скажут вам, что пункты меню и панели инструментов в приложении должны оставаться фиксированными, а не появляться и исчезать на лету. Во многом они правы. Но в случае чего-то вроде встроенного редактора изображений или инструмента отчетности, где у вас есть огромное количество настраиваемых параметров (шрифты, цвета, стили и т. Д.), Это может быть единственным способом решения проблемы без использования вашего плагина. в огромном количестве UI недвижимости, когда большую часть времени она не используется на самом деле. К счастью, NetBeans предоставляет способ справиться с этим. Обычно пункты меню и панели инструментов и другие компоненты пользовательского интерфейса регистрируются в файловой системе системы через файл слоя., Но вы также можете динамически добавлять и удалять слои из системной файловой системы:

    • Создать подкласс MultiFileSystem
    • Зарегистрируйте его в поиске по умолчанию, поместив плоский файл в JAR-файл вашего плагина в
      META-INF/services

      каталог.

    • Найти его во время выполнения через
      Lookup.getDefault().lookup(YourFilesystem.class)

      , Создайте новую файловую систему XML, указав на другой файл слоя, который регистрирует элементы, которые вы хотите отобразить. Добавьте / удалите его из MultiFileSystem, чтобы элементы, которые он регистрирует, появлялись и исчезали.

  • Replace the global selection model — Selection (action enablement, property sheet content, etc.) in the NetBeans IDE is based on which logical window has focus. The selection is represented as (yes), a Lookup — a thing like a map where the keys are Class objects and the values are one or more instances of that class, and to which you can subscribe for notification of changes in the set of instances of a given type. I blogged about a year ago about how applications which need a more Photoshop-style selection model (the active editor owns selection, everything else is a palette or something that responds to the editor’s selection). Your actions work the same way in the IDE or the standalone platform app — but the feel of the application is what makes sense for each one.