понедельник, 1 октября 2007 г.

Вывод ревизии subversion в приложениях Apex.

Как уже упоминалось ранее, зачастую приложение разворачивается на нескольких площадках. Соответственно, вполне логична ситуация, когда на двух и более площадках будут находиться различные версии одного и того же приложения. Поэтому достаточно часто в GUI выводят этот самый номер версии и, как правило, весь этот GUI распространяется по площадкам с помощью системы управлениями версиями Subversion.

Далее будет рассматриваться ситуация, когда приложение Oracle Application Express находится под управлением системы контроля версиями Subversion и стоит задача вывести в интерфейс номер svn-ревизии приложения.

Теория
Суть решения заключается в использовании одной из функциональностей Subversion - Keyword Substitution, которая позволяет при сохранении изменений выполнять замены ключевых слов. То есть, в файле, находящемся под управлением Subversion, может выводиться информация о дате или авторе изменения, о номере ревизии и т.д.).

Решение поставленной задачи состоит из нескольких этапов:


  1. Объявить строку замены (Substitution String) в apex-приложении

  2. Изменить шаблон приложения таким образом, чтобы использовалась новая строка подстановки

  3. Включить функциональность Keyword Substitution для файла приложения в Subversion


Практика. Определение строки замены
Для того чтобы определить свою собственную строку замены, необходимо перейти в "Shared Components -> Application -> Definition":


где перейти в раздел "Substitutions" и добавить новую строку замены, например SVN_REV (значение этой строки важно и изменять его не следует - "$Rev $". Это связано с особенностями работы Subversion - см. документацию по Subversion. Keyword Substitution):


Теперь, если посмотреть файл экспорта приложения (как это сделать описывалось ранее), то можно увидеть приблизительно такие строки (можно найти поиском по фразе "svn"):

p_substitution_string_01 => 'SVN_REV',
p_substitution_value_01 => '$Rev: $',

То есть, значение строки подстановки в файле экспорта лежит в открытом виде, которое можно изменять как угодно. Это нам пригодиться.

Практика. Изменение шаблона
Для того чтобы вывести номер версии в GUI, необходимо изменить шаблон, который отвечает за общий вид формы. Для чего необходимо перейти в "Shared Components -> User Interface -> Templates" и выбрать шаблон страницы:




После этого, необходимо прописать в шаблоне созданную ранее строку подстановки "SVN_REV", например так:


Теперь при работе приложения в нижнем левом углу будет следующая картина:


Практика. Включение Keyword Substitution
Основная часть работы уже сделана. осталась малость - включить функцию "Keyword Substitution" для файла, в котором располагается описание нашего приложения. Допустим, файл нашего приложения называется "apex_app.sql". Тогда включение будет выглядеть так:

drive:\path\to\svn\repository\svn propset svn:keywords "Date Revision Author" apex_app.sql

Вот и все. Теперь при каждом сохранении очередной версии файла apex-приложения будет вместо "$Rev $" прописываться актуальная версия файла в Subversion-репозитариии. То есть, в каждом файле приложения будет лежать строка подстановки с актуальной версией файла.
То есть, картинка в левом нижнем углу должна быть приблизительно такой:


Таким же образом можно выводить и последнего автора изменений или дату последнего сохранения в репозитарии.

ps: прошу прощения за столь значительную задержку в публикациях, ибо после сезона отпусков случился аврал :(, что отрицательно сказалось на количестве свободных минут.

10 комментариев:

Анонимный комментирует...

Добрый день.
Не нашел контакта, чтобы просто попросить помощи без написания комментария.
Вопрос не относится к последней новости.
В общем есть приложение развернутое на одной базе BD1. А теперь нужно создать приложение, которое берет данные совсем из другой базы BD2. И я не понимаю как это сделать.
При создании нового Workspace, предлагают выбрать схему, но схему только из юзеров, которые на базе BD1.
Как быть?
С уважением, Владимир.

Timoshinin Evgeny комментирует...

Добрый день, Владимир.

Обязательно ли в Вашем случае, чтобы новое приложение крутилось именно на DB1, а данные брало из DB2?

Дело в том, что архитектура apex'a такова, что его ядро лежит полностью в БД. То есть, все окружение apex'a жестко привязано в конкретной БД. Поэтому при создании нового приложения предлагаются схемы той БД, на которой установлен apex.

Поэтому решение в лоб - это выполнить установку apex'а на DB2 и там уже создавать новое приложение.

Если необходимо, чтобы приложение крутилось под DB1, то с помощью синонимов и линков можно легко обращаться к данным из любых БД.

Timoshinin Evgeny комментирует...

Насчет контакта - под каждым постом есть иконка для отправки email'a - "Отправить сообщение по электронной почте" :).

Анонимный комментирует...

только для отправки нужно знать Ваш электронный адрес.

Анонимный комментирует...

Пожалуйста, напищите мне
anton at anychart dot com

www.anychart.com

Анонимный комментирует...

Спасибо за статью про вывод ревизии. Интересен вопрос как вообще правильно огранизовать контроль версий для APEX. Я не нашел никаких ресурсов на эту тему кроме упоминния, что
APEX developers используют
subversion. Но как? Идеология subversion требует чтобы каждый девелопер редактировал свою собственную копию материала. Как это применимо к APEX, если учесть что экспорт/импорт компонентов, например страниц между разными приложениями не работает. Буду благодарен за информацию по этому вопросу.

Сергей

Timoshinin Evgeny комментирует...

...Спасибо за статью про вывод ревизии...
На здоровье! :). Главное - чтобы пригодилось!

...Интересен вопрос как вообще правильно огранизовать контроль версий для APEX...
Тоже долго размышлял/гуглил по этому поводу :). Пока никаких официальных рекомендаций, кроме как "Используйте Subverion и Apex Export/Import" я не встречал.

...APEX developers используют
subversion. Но как? Идеология subversion требует чтобы каждый девелопер редактировал свою собственную копию материала. Как это применимо к APEX...
Как мне кажется, есть 2 интерпретации этого вопроса:
1. Хранить в SVN полностью Apex приложение в одном файле. А работу над страницами вести в рамках одного приложения (использовать механизм Page Locking )
2. Хранить в SVN страницы приложения, разработку которых вести отдельно (разные workspace).

Вообщем, каждый из вариантов, необходимо опробовать... У нас в команде пока используется первый вариант.

...экспорт/импорт компонентов, например страниц между разными приложениями не работает...
Да, это так. Но это легко обходится :), например. Кроме того, в документации явно описана необходимость совпадения идентификаторов приложений на разных инстансах.

Sergey комментирует...

Какой толк от subversion при условии, что все редактируют одну копию? Бекап
делать? Можно и просто файловую систему
для этого приспособить с тем же успехом,
если конечно не считать автоматической подстановки номера ревизии. Получается, что этим вся полезность и ограничивается.Я не прав? Хотя если разработчик только один или все редактируют строго по очереди...

...экспорт/импорт компонентов, например страниц между разными приложениями не работает...
Да, это так. Но это легко обходится :), например. Кроме того, в документации явно описана необходимость совпадения идентификаторов приложений на разных инстансах.
Если бы это только работало! Мне не удалось получить положительный результат даже при совпадении идентификаторов.
Получал referential constraint violation при попытке втащить компоненты с одной машины на другую из приложения с тем же id. Я правда не пытался править workspace id в файле. Возможно в этом дело. Надо еще поизучать.

Timoshinin Evgeny комментирует...

Какой толк от subversion при условии, что все редактируют одну копию? Бекап делать?...
Во-первых, Бэкап, а во-вторых, subversion - как средство распространения приложения между dev/test/production инстансами. Кроме того, svn хорошо автоматизируется (для ночных сборок и т.д.)

...Можно и просто файловую систему для этого приспособить с тем же успехом,если конечно не считать автоматической подстановки номера ревизии. Получается, что этим вся полезность и ограничивается .Я не прав? Хотя если разработчик только один или все редактируют строго по очереди...
Подход следующий: в течении дня разработчики ведут какие-то работы над своими компонентами/страницами. Ночью же задание (cron или что-то подобное) экспортирует полностью приложение и помещает его в subversion. Таким образом, никто у кого из разработчиков не болит голова о сохранении истории своих изменений. И перенос любой версии приложения на другой инстанс становится проще.

...Если бы это только работало! Мне не удалось получить положительный результат даже при совпадении идентификаторов...
Необходимо так же совпадение workspace id.

Анонимный комментирует...

It is very interesting for me to read that article. Thanx for it. I like such themes and anything that is connected to this matter. I would like to read more soon.

Truly yours
Alice Tudes