С помощью фабрик элементов можно воссоздавать объекты модели рабочей среды из данных, сохраненных при выходе из рабочей среды.
Прежде чем подробнее познакомиться с расширением фабрики элементов, вспомним общие приемы, используемые в платформе для добавления поведения к обычным объектам модели рабочей среды.
Как можно заметить, многие интерфейсы рабочей среды расширяют интерфейс IAdaptable.
Модули используют адаптеры для добавления определенных функций к имеющимся типам в системе. Например, рабочая среда может потребовать от ресурсов предоставлять метку и изображение для отображения. Известно, что добавлять зависящие от пользовательского интерфейса функции к объектам низкого уровня нежелательно, но как добавить их к типам ресурсов?
Модули могут регистрировать адаптеры, которые добавляют функции к имеющимся типам. Затем код приложений может отправить запрос объекту для определенного адаптера. Если у приложения есть зарегистрированный адаптер, оно может использовать поведение, заданное в адаптере.
Такие средства для динамического запроса адаптера у объекта могут улучшить гибкость системы по мере ее развития. Новые адаптеры можно регистрировать для типов платформы с помощью новых модулей, не изменяя определения изначальных типов. Шаблон запроса адаптера у объекта выглядит следующим образом:
// создан ли объект o, нужный "рабочей среде". if (!(o instanceof IAdaptable)) { return null; } IWorkbenchAdapter adapter = (IWorkbenchAdapter)o.getAdapter(IWorkbenchAdapter.class); if (adapter == null) return null; // теперь можно обращаться с объектом o как с IWorkbenchAdapter ...
Если для выбранного объекта не зарегистрирован никакой адаптер, в качестве адаптера будет возвращено пустое значение. Клиенты должны быть готовы к такой ситуации. Может случиться так, что нужный адаптер не зарегистрирован.
Рабочая среда использует адаптеры для получения сведений от основных типов платформы, например IResource. Адаптеры защищают базовые типы от относящихся к пользовательскому интерфейсу сведений и позволяют рабочей среде развивать интерфейсы без необходимости изменять базовые определения.
Без адаптеров при передаче любого класса в API рабочей среды требуется применение интерфейсов пользовательского интерфейса, что увеличит число определений классов, и создаст тесную связь и круговые зависимости между классами пользовательского интерфейса и ядра. При наличии адаптеров классы применяют IAdaptable и используют реестр адаптеров, что позволяет модулям расширить поведение базовых типов.
В коде рабочей среды можно увидеть примеры запроса адаптера типом ядра платформы. Запрос используется для получения объекта, способного предоставить сведения о типе, связанные с пользовательским интерфейсом.
При выходе из рабочей среды будет сохранено текущее состояние объектов IAdaptable, отображаемых в рабочей среде. Состояние объекта запоминается за счет сохранения базовых параметров данных в специальном формате IMemento. ИД фабрики, которая сможет воссоздать объект из IMemento, также сохраняется, а данные сохраняются в файловой системе.
При перезапуске платформы рабочая среда находит фабрику элементов, по ИД фабрики IMemento. Она проверяет реестр модулей на наличие дополнений к расширению org.eclipse.ui.elementFactories.
Код довольно прост. Следует лишь указать ИД фабрики и соответствующий класс, применяющий фабрику.
Ниже приведен фрагмент кода из plugin.xml.
<extension point="org.eclipse.ui.elementFactories"> <factory class="org.eclipse.ui.internal.model.ResourceFactory" id="org.eclipse.ui.internal.model.ResourceFactory"> </factory> <factory class="org.eclipse.ui.internal.model.WorkspaceFactory" id="org.eclipse.ui.internal.model.WorkspaceFactory"> </factory> <factory class="org.eclipse.ui.part.FileEditorInputFactory" id="org.eclipse.ui.part.FileEditorInputFactory"> </factory> <factory class="org.eclipse.ui.internal.dialogs.WelcomeEditorInputFactory" id="org.eclipse.ui.internal.dialogs.WelcomeEditorInputFactory"> </factory> <factory class="org.eclipse.ui.internal.WorkingSetFactory" id="org.eclipse.ui.internal.WorkingSetFactory"> </factory> </extension>