Локалізація ADF 10g, Інші СУБД, Бази даних, статті

Локалізація 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:



Що таке локалізація і для чого вона потрібна

Строго кажучи, терміни локалізація та інтернаціоналізація різні. Перший означає представлення даних користувачеві відповідно до країни, територією і набором символів, які він використовує. Наприклад, формати дати, чисел, напрямок тексту (зліва направо, справа наліво) і є локалізація. Другий – користувачеві, як зазвичай буває, зручно працювати з програмами на його рідній мові, тобто бачити меню, розділи допомоги, діалогові вікна та інші елементи оформлення, перекладені на рідну мову. Це називається інтернаціоналізацією. Образно кажучи, дані, з якими працює користувач, локалізуються, а оформлення – інтернаціоналізується.

Для чого ж потрібна локалізація? Для задоволення вимог користувача, для залучення більшої кількості замовників, для підвищення конкурентоспроможності програмного забезпечення. Як правило, комерційний або великий проект, призначений не для однієї окремо взятої країни, не мине фази локалізації.

ADF, як промисловий framework, підтримує локалізацію розробляються на декількох рівнях. Локалізація (якщо розглядати загальноприйнятий термін) підтримується елементами представлення даних і залежить від обраних користувачем мовних і територіальних налаштувань. Інтернаціоналізація ж охоплює всі верстви фреймворка.

У цій статті для локалізації та інтернаціоналізації використовується один термін – локалізація.

Які шари локалізації існують в ADF

Згідно з концепцією ADF є наступні різновиди шарів програми:


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)

Рис. 5. Перехід до визначення сторінки

У вікні структури сторінки в розділі змінних (“variables”) можна побачити імена змінних (Мал. 6) сторінки, які асоційовані з аргументами бізнес-сервісів (“executables”) і повертаються ними значень.



Рис. 6. Перехід до властивостей змінних сторінки

Виберіть пункт контекстного меню “Properties” для того, щоб перейти до редагування властивостей змінних сторінки.

Редактор властивостей змінних (Мал. 7) аналогічний редактору редагування властивостей моделі.



Рис. 7. Редактор властивостей змінних сторінки

Архітектура

Архітектура аналогічна архітектурі бізнес-моделі. Для конкретної сторінки існує асоційований з нею файл властивостей. Наприклад, для сторінки pageDefinitionLevelLocalization.jspx існує її опис pageDefinitionLevelLocalizationPageDef.xml. Кореневий елемент опису містить атрибут (MsgBundleClass), значенням якого є файл властивостей містить локалізовані значення опису змінних (Мал. 8).

Рис. 8. Асоціація визначення сторінки і файлу java-bundle локалізації

Механізм локалізації аналогічний механізму локалізації біснес-моделі, однак, тільки схожий на механізм java-bundle. Відмінність полягає в тому, що середа виконання не шукає файли “* _ . Java”. Для реалізації підтримки декількох мов необхідна невелика доробка. Приклад доопрацювання представлений в. прикладі за адресою soa.it-consultants.ru:8888/?q=node/30.

Переваги та недоліки

Локалізовані описи, зроблені на рівні визначення сторінки, дійсні тільки для конкретної сторінки. Для їх повторного використання на інших сторінках необхідні доопрацювання. (Доопрацювання з наведеного приклад якраз дозволяє це зробити). Також до недоліків можна віднести неможливість роботи з декількома мовами без доопрацювання.

До переваг можна віднести можливість зберігати локалізовані рядки де завгодно: починаючи від java-bundle файлів і XML-файлів і закінчуючи базами даних.

Шар представлення даних
На рівні представлення даних можна локалізувати всі властивості бізнес-об’єктів: методи, змінні, атрибути та бізнес-сервісів і всі моделі. А також будь-рядкові константи.

Як використовувати

Для отримання цієї функціональної можливості необхідно просто перетягнути піктограму “LoadBundle” з палітри компонентів на робочу область сторінки (Мал. 9). (Піктограма знаходиться в розділі “JSF Code” палітри компонентів).



Рис. 9. Піктограма LoadBundle (ресурсу)

Відкриється майстер підключення файлу локалізації (Мал. 10), у другому необхідно вказати ім’я файлу і асоціювати його з ресурсом (змінної).



Рис. 10. Атрибути ресурсу локалізації

Тепер можна для будь-якого JSF компонента, що має рядкові атрибути, задати локалізоване значення оного. Зробити активним елемент управління на сторінці (клацнути по ньому лівою кнопкою миші), після цього у вікні інспектора властивостей вибрати необхідний атрибут, наприклад, “Text” і встановити його значення за допомогою майстра (Мал. 11).



Рис. 11. Установка локалізованого властивості

У майстрі вибрати розділ “JSP Objects”, ім’я асоційованого ресурсу (“locale”) і ідентифікатор локалізуемой рядки (“panel.business_service.button”) – Рис. 12.

Рис. 12. Вибір ключа локалізації

Архітектура

Механізм локалізації на рівні представлення даних заснований на механізмі Java-bundles. Підтримуються як java-класи, так і файли властивостей (*. Properties). При описі сторінки існує можливість помістити там посилання на ресурс, що містить локалізовані рядки (Мал. 13). На одну сторінку можна помістити кілька ресурсів.



Рис. 13. Налаштування сторінки для завантаження ресурсу локалізації

Для отримання локалізованих сторінок на етапі виконання необхідно встановити в інтеренет-барузере відповідну мову. Якщо підтримки необхідного мови немає (не було зроблено на етапі проектування), то буде використовуватися мова “за замовчуванням”. Мова “за умовчанням” (і всі підтримувані мови) задається у файлі конфігурації програми (Мал. 14).



Рис. 14. Налаштування програми для підтримки локалізації

Є можливість зробити зміну мови користувачем під час виконання. Для цього необхідно реалізувати свій, так званий, phase-listener. З прикладом реалізації можна ознайомиться в наведеному проекті.

Переваги та недоліки

Даний спосіб локалізації підтримує як Java-bundles, так і файли властивостей. Є можливість повторно використовувати створені файли локалізації, для цього необхідно просто описати їх як ресурс на сторінці. Є можливість при використанні Java-bundle зберігати локалізовані рядки, як в java-класах, так і в XML файлах або базі даних. Однак, необхідно кожен раз для кожного атрибута вказувати ключ локалізованого значення.

Висновок


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*