Локализация ADF 10g
Введение
|
|
Эта статья по локализации и интернационализации начинает цикл статей по теме Oracle Application Development Framework (ADF) 10 g . В ней рассматриваются некоторые вопросы, относящиеся к локализации и интернационализации приложений, созданных с помощью технологии ADF. В статье выявляются уровни локализации приложений, рассматривается возможность их использования, отмечаются недостатки и преимущества использования каждого уровня. Для лучшего понимания и наглядности процесса локализации разработано небольшое приложение, которое можно загрузить по адресу http://soa.it-consultants.ru:8888/?q=node/30. В качестве среды разработки использовалось интегрированное средство разработки Oracle JDeveloper 10 g (10.1.3.3). Приложение представляет собой два проекта в JDeveloper: |
- Model - проект, в котором находится локализируемый бизнес-сервис, представленный обычным Java-классом, и его метаописание;
- ViewController - проект, в котором определены привязки бизнес-сервисов и несколько ADF Faces страниц, показывающие уровни локализации.
Что такое локализация и для чего она нужна
Строго говоря, термины локализация и интернационализация разные. Первый означает представление данных пользователю в соответствии со страной, территорией и набором символов, которые он использует. Например, форматы даты, чисел, направление текста (слева направо, справа налево) и есть локализация . Второй - пользователю, как обычно бывает, удобно работать с программами на его родном языке, то есть видеть меню, разделы помощи, диалоговые окна и прочие элементы оформления, переведенные на родной язык. Это называется интернационализацией . Образно говоря, данные, с которыми работает пользователь, локализуются, а оформление - интернационализируется.
Для чего же нужна локализация? Для удовлетворения требований пользователя, для привлечения большего количества заказчиков, для повышения конкурентоспособности программного обеспечения. Как правило, коммерческий или большой проект, предназначенный не для одной отдельно взятой страны, не минует фазы локализации.
ADF, как промышленный framework, поддерживает локализацию разрабатываемых приложений на нескольких уровнях. Локализация (если рассматривать общепринятый термин) поддерживается элементами представления данных и зависит от выбранных пользователем языковых и территориальных настроек. Интернационализация же охватывает все слои фреймворка.
В этой статье для локализации и интернационализации используется один термин - локализация .
Какие слои локализации существуют в ADF
Согласно концепции ADF имеются следующие разновидности слоев приложения:
- первый слой - бизнес-сервисы (модель данных и привязок);
- второй слой - контроллер (в ADF Swing он реализован согласно технологии Swing);
- третий слой - представление.
- Тем самым можно выделить следующие слои (или уровни) локализации:
- слой описания модели бизнес-сервисов;
- слой описания привязок модели;
- слой представления.
ADF дает возможность независимо настраивать параметры локализации, для каждого из указанных слоев.
Слой описания модели
Первым шагом использования ADF является создание метамодели бизнес-сервисов(Рис. 1).
Рис. 1 . Добавление метаописания бизнес-сервисов в проект Model
Сам бизнес-сервис BusinessService достаточно прост и имеет два атрибута (businessAttribute и modelLocalizationAdditionalInformation) и один метод (invokeHelloService). В метаописание бизнес-сервиса входит описание всех объектов предметной области, с которыми оперирует этот бизнес-сервис. На этом уровне ADF позволяет локализовать описания объектов предметной области и их атрибутов, в том числе и сложных. Локализовать описание методов бизнес-сервисов на данном уровне невозможно.
Как использовать
После того, как получено метаописание бизнес-сервиса, можно локализовать описание объектов предметной области или атрибутов бизнес-сервисаР (Рис. 2).
ис. 2. Атрибуты бизнес-сервиса
Важно понимать, что атрибутами бизнес-сервиса могут быть как примитивные, так и сложные типы, которые являются объектами предметной области вне зависимости от их атрибутов сложности.
Для того чтобы начать локализовать описание атрибута необходимо сделать двойной щелчок мыши на выбранном атрибуте или выбрать раздел "Properties" из контекстного меню. После этого появится диалог со свойствами атрибута (Рис. 3), который позволяют настроить отображаемые презентационным слоем свойства атрибута.
Рис. 3. Свойства атрибута
Следует отметить, что если вдруг возникнет необходимость пересоздать метаописание какого-то объекта предметной области или бизнес-сервиса, то внесенные описания не потеряются.
Что же происходит за кулисами? Все просто: с описанием объекта предметной области или бизнес-сервисом ассоциируется файл свойств. Ссылка на него содержится в атрибуте MsgBundleClass (корневой элемент метаописания объекта предметной области - Рис. 4), значением которого является имя файла свойств.
Рис. 4. Ассоциация бизнес-сервиса и файла свойств
Например, для бизнес-сервиса BusinessService существует файл метаописания BusinessService.xml, коневым элементом которого является элемент JavaBean, а у корневого элемента есть атрибут MsgBundleClass, значением которого является имя ассоциированного с бизнес-сервисом файла свойств - oracle.samples.j2ee.adf.localization.model.BusinessServiceMsgBundle.
Механизм локализации основан на Java-bundle, который содержит описания атрибутов бизнес-сервиса, внесенные мастером. В качестве файла свойств как раз и выступает такой Java-bundle. Следует отметить, что уровень локализации модели ADF поддерживаются только пакеты ресурсов - Java-классы. Это, с одной стороны, не дает возможность такой быстрой локализации, как через java-механизм
*.properties-файлов, но с другой стороны дает отличную возможность использовать в качестве back-end"а любое хранилища строк от XML и до базы данных.
Преимущества и недостатки
Локализация, представленная на уровне модели, является первичной. Среда выполнения ADF будет подставлять (по умолчанию) значения локализованных строк везде, где производится обращение к объектам предметной области и их атрибутам. Соответственно, нет необходимости определять свойства локализации для каждой страницы или экранной формы. С другой стороны, если возникает необходимость представлять другое описание атрибута бизнес-сервиса, то это невозможно сделать средствами модели. Описания глобальны для всего приложения. Для подстройки под контекст, используются другие уровни локализации: привязки и представления.
Мастер локализации (Рис. 3) позволяет работать только с одним языком. Для того чтобы с помощью мастера настраивать разные файлы свойств (java-bundle) необходимо изменить имена файлов. Например, чтобы работать с русским языком, необходимо переименовать файл BusinessServiceMsgBundle_ru.java в BusinessServiceMsgBundle.java до начала редактирования, и проделать обратную операцию после окончания редактирования.
Слой описания привязок ADF
На этом уровне локализируются только имена аргументов методов бизнес-сервисов.
Как использовать
После того как создана страница, в которой предполагается использовать бизнес-сервисы и локализовать аргументы методов, необходимо перейти к описанию бизнес-модели страницы. Для этого необходимо в навигаторе приложения выбрать jsf-страницу, щелкнуть на ней правой кнопкой мыши и выбрать пункт контекстного меню "Go to Page Definition" (Рис. 5)
В окне структуры страницы в разделе переменных ("variables") можно увидеть имена переменных (Рис. 6) страницы, которые ассоциированы с аргументами бизнес-сервисов ("executables") и возвращаемых ими значений.
Выберите пункт контекстного меню "Properties" для того, чтобы перейти к редактированию свойств переменных страницы.
Редактор свойств переменных (Рис. 7) аналогичен редактору редактирования свойств модели.
Архитектура
Архитектура аналогична архитектуре бизнес-модели. Для конкретной страницы существует ассоциированный с ней файл свойств. Например, для страницы pageDefinitionLevelLocalization.jspx существует ее описание pageDefinitionLevelLocalizationPageDef.xml. Корневой элемент описания содержит атрибут (MsgBundleClass), значением которого является файл свойств (oracle.samples.j2ee.adf.localization.view.pageDefs.pageDefinitionLevelLocalizationPageDefMsgBundle), содержащий локализованные значения описания переменных (Рис. 8).
Механизм локализации аналогичен механизму локализации биснес-модели, однако, только похож на механизм java-bundle. Отличие состоит в том, что среда выполнения не ищет файлы "*_<language_code>.java". Для реализации поддержки нескольких языков необходима небольшая доработка. Пример доработки представлен в . примере по адресу http://soa.it-consultants.ru:8888/?q=node/30.
Преимущества и недостатки
Локализованные описания, сделанные на уровне определения страницы, действительны только для конкретной страницы. Для их повторного использования на других страницах необходимы доработки. (Доработка из приведенного примера как раз позволяет это сделать). Также к недостаткам можно отнести невозможность работы с несколькими языками без доработки.
К преимуществам можно отнести возможность хранить локализованные строки где угодно: начиная от java-bundle файлов и XML-файлов и заканчивая базами данных.
Слой представления данных
На уровне представления данных можно локализовать все свойства бизнес-объектов: методы, переменные, атрибуты и бизнес-сервисов и все модели. А также любые строковые константы.
Как использовать
Для получения этой функциональной возможности необходимо просто перетянуть пиктограмму "LoadBundle" из палитры компонентов на рабочую область страницы (Рис. 9). (Пиктограмма находится в разделе "JSF Code" палитры компонентов).
Откроется мастер подключения файла локализации (Рис. 10), во втором необходимо указать имя файла и ассоциировать его с ресурсом (переменной).
Теперь можно для любого JSF компонента, имеющего строковые атрибуты, задать локализованное значение оного. Сделать активным элемент управления на странице (щелкнуть по нему левой кнопкой мыши), после этого в окне инспектора свойств выбрать необходимый атрибут, например, "Text" и установить его значение с помощью мастера (Рис. 11).
В мастере выбрать раздел "JSP Objects", имя ассоциированного ресурса ("locale") и идентификатор локализуемой строки ("panel.business_service.button") - Рис. 12.
Архитектура
Механизм локализации на уровне представления данных основан на механизме Java-bundles. Поддерживаются как java-классы, так и файлы свойств (*.properties). При описании страницы существует возможность поместить там ссылку на ресурс, содержащий локализованные строки (Рис. 13). На одну страницу можно поместить несколько ресурсов.
Для получения локализованных страниц на этапе выполнения необходимо установить в интеренет-барузере соответствующий язык. Если поддержки необходимого языка нет (не была сделана на этапе проектирования), то будет использоваться язык "по умолчанию". Язык "по умолчанию" (и все поддерживаемые языки) задается в файле конфигурации приложения (Рис. 14).
Есть возможность сделать смену языка пользователем во время выполнения. Для этого необходимо реализовать свой, так называемый, phase-listener. С примером реализации можно ознакомится в приведенном проекте.
Преимущества и недостатки
Данный способ локализации поддерживает как Java-bundles, так и файлы свойств. Имеется возможность повторно использовать созданные файлы локализации, для этого необходимо просто описать их как ресурс на странице. Есть возможность при использовании Java-bundle хранить локализованные строки, как в java-классах, так и в XML файлах или базе данных. Однако, необходимо каждый раз для каждого атрибута указывать ключ локализованного значения.
Заключение
- При проектировании полноценных приложений следует использовать все рассмотренные подходы:
- уровень модели - для описания глобальных (для всего приложения) локализованных строк.
- уровень описания страницы - для описания аргументов бизнес-сервисов.
- уровень представления для пользовательских локализаций.