JDeveloper, Настройка кодировки

В JDeveloper определяются IDE encoding - кодировка чтения записи файлов, Compiler Encoding - кодировка используемая при компиляции ява файлов.

Для их настройки используйте:

* IDE encoding - Tools|Preferences... menu -> Environment.
* Compiler Encoding - Tools|Project Properties... menu and select Compiler.

Локализация ADF Faces

Локализация в ADF Faces используется при генерации стандартных сообщений, елементов ( например при использовании элемента tree), а также при форматировании вывода чисел и дат. По умолчанию берется локализация ОС в которой запущен OC4J.
Локализацию можно задать явно. Для этого в файле faces-config.xml нужно указать:
<faces-config xmlns="http://java.sun.com/JSF/Configuration">
...
   <application>
   ...
   <locale-config>
      <default-locale>ru</default-locale>
   </locale-config>
   </application>
</faces-config>

Краткий справочник по книге "Business Rules in ADF BC" An Oracle White Paper August 2007

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

Бизнес Правила(БП) можно разделить:

1. Правила отвечающие состояниям системы
2. Правила отвечающие за изменение сотояний системы
3. Правила Авторизации
   
4. автоматические тригеры, запускающие определенные действия при изменении состояния системы.

UML концепции БП:

1. Инварианты - ограничения определяющие систему в стабильных состояниях. Обычно включаются в UML модель классов
2. Предусловия - условия которые должны быть выполнены, для возможности перехода из одного состояния системы в другое. Обычно описываются в use-case диаграммах
3. Постусловия - условия которые должны быть выполнены после перехода системы в новое состояние. Обычно описываются в use-case диаграммах

автоматические действия не являются бизнес правилами.

В книге рассмотрены такие БП:

1. Constraint - ограничения на состояние системы и на переход из одного состояния в другое
2. Change Event - определяют действия запускаемые при определенных условиях. (Пример: при определенном условии напечатать отчет или послать имеил)
3. Authorization - ограничения связанные с авторизацией

Constraint rules:

Описывают ограничения на состояние системы и на переход из одного состояния в другое. Соответствуют UML инвариантам и UML пред условиям.

Constraint rules делят по обьектам к которым они относятся:

1. Attribute - правило для конкретного атрибута одного обьекта
2. Instance - правило для нескольких атрибутов одного обьекта
3. Entity - правило для нескольких обьектов одного типа ентити
4. MultyEntity - правило для более одного обьекта разных типов сущностей
   

Attribute:

1. Attribute properties - ограничивает состояние атрибута:
   
   • Type - ограничение по типу атрибута (Пример: Departament должен быть Numeric)
   • Mandatory - определяет является ли атрибут обязательным
   • Updateble - определяет можно ли атрибут менять (Пример: OrderLine нельзя назначить другому Order (OrderLine.OrderId not Updateble)
2. Domain - позволяет задать свой тип даных для атрибута (Пример: Поле YesNo может принимать значения либо "Y", либо "N")
3. Validation:
   
   • Compare (Пример: Зарплата сотрудника должна быть больше 0)
   • List (Пример: состояние сотрудника должно быть одним из списка "S" (Single), "M" (Married), "D" (Divorced), "W" (Widowed) или null)
   • Renge (Пример: бюджет должен находится в пределах от 10 000 до 100 000)
   • Length (Пример: Код страны должен состоять из 2-х символов)
   • Regular (Пример: Почтовый код должен иметь формат **-**)
   • Method (Пример: состояние сотрудника может меняться только по правилам: divorced, widowed -> married; married -> divorced, widowed; null -> any value; any value -> null)

Instance:

1. Instance Validator - реализуется с помощью метода в классе ентити или с помощью отдельного класа. (Пример1 : Рабочий который числится как "SALESMAN" обязательно должен иметь заполненное поле с комиссией) (Пример2: Нельзя изменять Rate, Role или PercentageAllocated для ProjectAssignment если он активен. (Закройте активный ProjectAssignment и создайте новый) (Пример3: Дата начала должна быть меньше даты конца)
2. Delete Rules - запрещает удалять запись при определенных условиях (пример: Вы не можете удалять Заказ после доставки)
   

Entity:

1. Unique Identifier - параметр среди всех обьектов данного типа ентити должен быть уникальным (Пример: название департамента должно быть уникально)
2. Collection, no parent - ограничение относится к коллекции обьектов но не к родителю этой коллекции (Пример: В системе не может быть больше 20 департаментов)
3. Other Entity - все остальные ограничения относящиеся к набору обьектов одного типа ентити

Multi Entity

1. Association - описывает как классы ентити зависят друг от друга (Пример: каждый OrderLine должен иметь один и только один order) (Пример2: каждый сотрудник работает только в одном департаменте)
2. Collection within Master(Parent) - ограничение касается коллекции и ее родителя (Пример: в департаменте должно быть не более одного работника-клерка)
3. Simple Multi Entity - включают правила которые связаны с различными типами ентити, но которые применяются только к одному енити. (пример: вы не можете создать проектное задание потому что проект закрыт (дата проекта в прошлом))
4. Complex Multi Entity - правила которые затрагивают много ентити и относятся также ко многим ентити.(пример: начальная дата проектного задания, должна попадать в диапазон даты начала и конца проекта)

Change Event rules:

Автоматические действия срабатываемые при изменении состояния системы

DML (Data Manipulation) - означают события связанные с операциями Create, Update, Delete

Change Event rules делят:

1. Change Event rules with DML - связаные с опреацыями Create, Update, Delete
2. Change Event rules without DML - не связаные с опреацыями Create, Update, Delete

Change Event rules with DML

1. Default - Правила описывают какое значение должно принять поле в случае операции Create
   
   • Literal (Пример: По умолчанию после создания записи поле count должно содержать значение 1)
   • Calculated (Пример: При создании записи генерить Id на основании последовательности из БД)
2. Change History Rules - запись в обьект информации о том когда и кем он был создан или модифицирован
3. Other Derivaion Rules - При создании или изменении обьекта пересчитать значение атрибута (Пример: при записи переcчитывать значение totalPrice)
4. Cascade Delete Rules - Удаление потомков при удалении родителя
5. Other - все остальные правила не вошедшие в описанные выше случаи. (Пример1: Если изменилась дата начала проекта, то нужно изменить все даты начала проектных задач, которые получаются раньше новой даты начала проекта) (Пример2: если изменилось значение зарплаты или комиссии сотрудника, записать соответствующее сообщение в журнал)

Change Event rules without DML

Автоматический триггер отслеживающий изменение системы не связанное с опреациями Create, Update, Delete (Пример: послать email сообщение менеджеру когда изменится дата окончания проектной задачи

Обновление данных на странице

При использовании ADF, доступ к ViewObject-ам (см ADV BC) из ADF Faces страниц осуществляется через итераторы (<itarator>) binding контейнеров соответствующих страниц, которые описываются в pageDef файлах. Тег <itarator> имеет очень важный атрибут Refresh который позволяет указать в каких случаях необходимо обновлять данные:

• always - при каждом запросе binding контейнера (при рендеринге страницы, при сабмите страницы или когда приложение отсылает ответ на страницу)

• deferred - отложенное. Обновляется только если этого требует другой (связанный с нашим) binding объект

• ifNeeded - (по умолчанию) обновляет даные при необходимости. Если например выводятся на страницу дочерняя и родительская таблица, то родитель будет обновлен два раза (один - при обновлении дочернего итератора, другой - при обновлении своего). ifNeeded - позволяет этого избежать.

• never - используется для того чтоб отключить обновление средствами ADF, при этом приложение должно само обновлять данные.

• prepareModel - используется если обновление требуется только при подготовке binding контейера страницы

• prepareModelIfNeeded - при подготовке контейнера и только если необходимо

• renderModel - обновлять при рендеринге страницы

• renderModelIfNeeded - обновлять при рендеринге страницы и только если необхлдимо

Для дополнительных условий можно использовать атрибут RefreshCondition - он позволяет задать EL выражение определяющее когда обновлять данные. Например: ${!bindings.findAllServiceRequestIter.findMode} обновление будет определятся значением атрибута findMode

Отладка ADF Faces

Очень удобно во время разработки ADF FAces приложений включить функцию отладки. Она позволит получать читабельный код клиента и вести отладку сгенерированного JavaScript. Для этого добавте следующие строки в файл web.xml:
<web-app>
...

<context-param>
<param-name>oracle.adf.view.faces.DEBUG_JAVASCRIPT</param-name>
<param-value>true</param-value>
</context-param>

</web-app>

Использование properties файлов

Хорошей практикой загрузки properties файлов является использование метода getResourceAsStream() класса java.lang.ClassLoader.
Пример:

 ClassLoader cl = this.getClass().getClassLoader();
InputStream is = cl.getResourceAsStream();
Properties props = new Properties();
try {
   props.load(is);
}...

при этом следует помнить что корневой каталог будет меняться в зависимости от типа контейнера.
Для сервлетов он будет начинаться с корня war файла. т.е. мы получим что-то типа:
...getResourceAsStream("/WEB-INF/propfile.props");
Для EJB он будет начинаться с корня jar файла. т.е. код будет иметь вид:
...getResourceAsStream("/somepackage/propfile.props");
Если же properties файл используется в jar который упакован в war файл, или же он вызывется из другого jar файла, то необходимо указывать относительный путь
...getResourceAsStream("somepackage/propfile.props");
. При этом следует убедится что properties файл находится в области видимости (для jar файлов ссылки на другие пакеты можно задать в файле MANIFEST.MF:
Manifest-Version: 1.0
Class-Path: lib1.jar lib2.jar lib3.jar
Created-By: Oracle JDeveloper 10.1.3.2.0
).При чтении (записи) данных в properties файлы используется кодировка ISO 8859-1. При использовании других кодировок необходимо произвести преобразование строк. Например так:

label = new String(label.getBytes("ISO-8859-1"), "UTF-8");

Оригинал статьи

ORACLE. Деплой приложений с помощью Ant

Oracle предоставляет Ant таски, для деплоя web или ear приложений. Для их использования необходимо:

• 1. Обьявить пространство имен oracle в вашем build.xml файле. Например так:
  <project name="test" default="all" basedir="." xmlns:oracle="antlib:oracle">


• 2. Добавить переменые oracle.home, oc4j.home, java.home. Первые два содержат пусть к OC4J последняя путь к JRE. Для этого в build.xml можно например добавить строку:
  <property file="build.properties"/>
  файл build.properties должен содержать строки:
  

  # The installation directory for OC4J (shared librery for ant deploy tasks)
  oracle.home=C:/Progs/OC4J
  oc4j.home=C:/Progs/OC4J
  # The home location for the JDK installation
  java.home=C:/home/progs/JDeveloper/jdk/jre

  
  


• 3. Включить ant-oracle.xml в build.xml. Файл ant-oracle.xml расположен {OC4J}/j2ee/utilities. Его можно скопировать в папку с проектом а затем в build.xml добавить строку: <import file="ant-oracle.xml"/>

Оригинал статьи