BiTel

В следующих версиях планируется перевод Web интерфейса с движка XSLT на JSP.

Из плюсов:
1) Выше скорость работы.
2) Проще разработка шаблонов, больше возможностей.

Из минусов:
1) Затруднительная интеграция с остальным XML фреймворком биллинга. Например, генерация информации по договору в XML документ сейчас используется как при генерации счетов/фактур так и страницы Web статистики (возможность вывода в кабинете доп. данных).
2) Неединнобразность используемых технологий, необходимость доп. обучения разработчиков.
3) Более сложный просмотр передаваемых данных в JSP шаблон нежели вывод XML документа просто добавлением ct=xml в запросе.

Просьба заинтересованных высказаться.

Про себя скажу, что функционал XSLT для меня недостаточен.
Почитал про JSP немного, возможности понравились. В общем я приветствую переход на JSP, хотя с ним и не знаком.

Только подготовьте пожалуйста несколько примеров, таких как http://wiki.bgbilling.ru/index.php/XSLT только для JSP.
И еще прошу разработчиков подумать по поводу затирания шаблонов при обновлении. Может быть придумаете что нибудь посерьезнее чем переименование файлов в *.orig ?

Есть более удобные вещи для веб-приложений, чем JSP. Velocity, например.

Ну JSP - компилируется, Velocity - нет. К JSP можно прикрутить Velocity.

Как обычно вам виднее.

Сделайте хотя бы нормальные beans, что бы JSP не превращались в кошмар.

Это что такое?

Разумеется, не будет чистых JSP вперемешку с тегами! Никих там <% %>. Будут шаблоны, JSTL итд итп.
Велосити - это совсем другой уровень уже, не путайте одно с другим. JSP это общая технология, к ней прикручивается что угодно выше, фреймвоки всякие, велосити итд

_________________
I'm clever. I've got a computer.

А вот как об этом можно было догадаться по "В следующих версиях планируется перевод Web интерфейса с движка XSLT на JSP." ?



В той же Турбине Велосити прекрасно работает без посредничества JSP.

Никак, наверно) Мы сами до конца ещё не поняли всего этого - как именно прикрутить к биллингу. Но опыты в наших лаборатириях кипят .

_________________
I'm clever. I've got a computer.

Ну так а я про что. Велосити - это сверху, просто шаблонизатор.
С турбиной то же самое - прикручивается к ней велосити или jsp или что-то ещё.

_________________
I'm clever. I've got a computer.

да, Да, ДА!!! может будете просто выкладывать веб отдельно с описанием измений того что добавилось/удалилось? а то каждое обновление - это как прогулки по минному полю - взорвет или не взорвет затрет или не затрет ... с библиотеками и базой понятно - делайте что считаете нужным, ну хоть веб то нам оставьте

Ну, это нереально - всё описать до мелочей. Как вы это себе представляете? Опишите подробнее, или с примером.

Если хотите отличий видеть - просто сравнивайте каждый раз свои редактированные файлы с оригиналом с помощью какой-либо программы типа windiff или meld и глядите что именно поменялось, и руками напатчивайте. Автоматический патчер тоже, как понимаете, проблематично сделать.

_________________
I'm clever. I've got a computer.

Что до автоматического патчера, то я с вами согласен, сделать сложно.
Но КАЖДЫЙ РАЗ сравнивать, что изменилось тоже не вариант, вы нас тоже поймите, мы тоже можем на изменять ваши шаблоны так что не сразу и сообразишь потом что и где потом править.
Для начала хочу вам предложить сделать следующее. Все данные из шаблона, которые каждый меняет для себя сам, стоит записать в переменные, которые будут определяться в конфиге сервера. Такие как:
1. Логотип.
2. Всевозможные вспомогательные комментарии в шаблоне error.xsl, типа "Номер договора состоит из нескольких букв в начале, затем несколько цифр, затем тире "-" и две
цифры (последние две цифры от года, когда был заключен договор). Номер вводиться слитно без пробелов. Например: NK00001-05, КФ123456-06 и т.д."
3. Номера телефонов расчетной службы.
4. Какой использовать файл стилей, вместо стандартного style.css.
ну и т.д.

Менюшки и action:
Менюшки тоже можно было бы вытащить к конфиг. А action в отдельные файлы.
Т.е. для каждого action создать отдельный шаблон.
Таким образом нам врятли придется править ваши стандартные шаблоны. Если нам будет нужен свой, то мы прописываем в конфиге сервера новый action и создаем отдельный шаблон для него.

Сделайте хотя бы это, думаю что жизнь нам упростите точно.

Ничего не понял. Не вижу никаких отличий от того, что сейчас. Или вы хотите свои action писать? Так вы и сейчас можете это делать. Что вы вообще подразумеваете под action, как его в файл то вытащить? Экшен - это java-класс, который формирует xml , которая трансформируется с помощью xsl в страницу.

_________________
I'm clever. I've got a computer.

Понятно что мы можем писать свои action.
Но для того что бы они были доступны на статистике нам необходимо поправить шаблоны common.xsl и main.xsl.
Я предлагаю рассмотреть вариант, при котором нам не придется править стандартные шаблоны.
Можно сделать например так:
1. Все менюшки будут определяться не в шаблонах, а в другом месте, например в конфиге сервера.
2. Все шаблоны, для менюшек (action), будут поделены по принципу: одна менюшка (action) - один шаблон.

В итоге у нас в конфиге сервера будут записи типа:
web.action.1.name = Просмотр баланса
web.action.1.action = ShowBalance
web.action.1.mid = contract
web.action.1.xsl = show_balance.xsl

Объясняю как могу

Вероятно будет толк от применения шаблонов типа "алгоритм" и других "делегирующих полномочия". Но нужен ли весь этот самолет с бассейном и стадионом?

Я конечно слоупок, однако JSP штука тоже не быстрая. В целом JSP будет приятней, чем ХSLT наверное.

Как так не быстрая? Уж побыстрее чем php/ruby/perl/...

_________________
I'm clever. I've got a computer.

Быстрее чем первое, это точно. Насчёт остального я точно не знаю. Однако метод ОБС от человека занимающегося написанием entrprise-java довольно успешно меня убедил, что если есть возможность не использовать jsp, то лучше его не использовать, особенно при больших нагрузках по числу запросов.
Может как нибудь python?

товарищи разработчики! Предлагаю довольно простой способ избавиться от *.orig файлов.
Ваш инсталлятор, или патчер пусть держит в себе список файлов, и md5 суммы к ним. При обновлении патчер берет md5 от уже существующего шаблона и соравнивает его с тем, что хранится в его списке. Если md5 один и тот же, прото перезаписывает, если md5 разный, то спрашивает, заменить, или оставить, или просто создает каталог, допустим, new_ДДММГГ, и в него складывает новые шаблоны, чьи md5 не совпали с существующими шаблонами, ну и выводит в конце установки/апдейта соответствующее сообщение

_________________

using billingClient.BGB 4.6;
using server.Ubuntu server 9.10;
using server.Java "1.6.0_15";
using client.Ubuntu 10.04;

Всё это для поставленной задачи будет работать примерно одинаково по скорости. Только в нашем случае что-либо, кроме jsp будет сложнее прикрутить.

_________________
I'm clever. I've got a computer.

Задумал глобально переделать личный кабинет. Вот только с переходом на jsp теперь не уверен, стоит ли начинать сейчас, или таки подождать.
Вообще, как будет выглядеть схема работы биллинга с jsp?

Сейчас схема такая: WebAction -(xml-data)->xsl->html
Мы можем: писать свои WebAction, менять xsl. Глобально менять структуру сборки кучи xsl-файлов не очень удобно, основные экшены обрабатываются в main.xsl, экшены модулей - в xsl этих модулей.

Опишите, как будет выглядеть этот процесс для jsp? И будет ли оно интегрировано с текущей схемой? Или придётся писать на jsp свой личный кабинет с нуля?

Работы по переходу на jsp пока временно заморожены .

Ок, спасибо. Буду пилить xsl

Незабывай в wiki выкладывать Интересно же....

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений