BiTel

собсно сабж ...
господа разработчики, давайте уже отходить от GUI клиента и переходить к full-featured ajax веб интерфейсу, а?
давайте развиваться, а то БГБ, при всей его "фичастости" может попросту оттолкнуть потенциальных (текущих?) пользователей в пользу продуктов имеющих web based управление

на дворе тотальный ajax в web приложениях, а мы, как доисторические ящеры, пользуемся GUI клиентом у которого, по хорошему, должен быть хотя бы Java Web Start ну или что угодно, лишь бы запуск клиента осуществлялся по одному клику на ссылке

Мне вот ради познания. А чем гуй хуже вебморды? Для саморазвития.

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Клиент устраивает и такой (хотя иногда возникает желание добавить своих кнопочек в интерфейс).

А вот личный кабинет напрягает. Совершенно невозможно содержать собственный набор xsl, т.к. при каждом апдейте приходится сравнивать, что там поменяли и вносить у себя соответствующие правки (особенно громадный main.xsl). Хочется продуманного разработчиками механизма кастомизации личного кабинета, чтобы чётко было определено, за какие файлы отвечает клиент, какие файлы трогать нельзя, при важных изменениях описывать подробно, что нужно сделать и т.п.
Давно хотел написать пост на эту тему, да руки не доходят обмозговать всё.

тем что сейчас GUI требуется компьютер с Java машиной и довольно немаленьким дисплеем (рекомендовано, ЕМНИМС, min 1024х768), а при наличии веб интерфейса достаточно браузера с поддержкой javascript, т.е. практически любого современного браузера и биллингом можно управлять даже с наладонника/телефона


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

тоже убивает при обновлениях меня все, подтачивать...

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Same here, только делаю diff старых файлов от разработчиков с их более новыми версиями.

+ иногда может смениться структура ответа xml от сервера.

Как раз вчера этим и занимался. Ранее просто перетирал файлы своими. Вчера все таки взял сравнил мои файлы и то что поставилось при последнем обновлении (с созданием orig файлов). Ничего сверх серьезного кроме передачи cid в вебке не нашел

судя по кол-ву постов от snark'а у него наболело. сарказмом не считать!

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

В данный момент у нас уже есть немалый функционал в клиенте, перетащить все это в web-это как-минимум трудоемкая задача . Это будет долго, дорого(так на это уйдет много человечасов) и в результате мы получим тот же самый функционал . Плюсы от этого должны очень заметно перевешивать все затраты .

menu.xml и toolbar.xml в ./data/
Хотя если речь о чем то более специфическом - умываю руки.

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

В html-коде в веб-статистике наткнулся:


У разработчиков уже jQuery не было желания использовать?
Красивости там всякие, ajax всяческий..

Phricker, спасибо, поковыряюсь в следующий раз, когда накроет.

jquery сотоварищи в текущем вебе сейчас только разве что для валидации полей да сортировки списков использовать можно (да и то это из пушки по воробъям, IMHO), т.к. текущий веб в общем то статичен, динамики в нем практически ноль ... аякс даже прикручивать некуда ... не, конечно можно даже щас, например на смену тарифа, прикрутить аяксовое "появление" строчки в таблице с тарифами при его смене, ну или на понижении лимита или еще где нить, ну а толку от этого? веб то по сути - статика

GWT?

Ну Java Web Start, насколько я понимаю, вы можете сами прикрутить, да и вообще , это кажется уже не особо прижившаяся технология.. Если расшарить клиента в сети , то его тоже можно запускать по одному клику , проблемы тут нет .. Да и клиент сам умеет обновляться при старте

Ну можно сделать клиентскую статистику динамической .. на gwt нем быстрее разрабатывать ..Но это пока теоретическое утверждение, мы не пробовали эту библиотеку. А то что при текущих используемых технологиях gui - рисовать быстрее, чем web - это факт . Можно подумать в этом направлении в отношении личного кабинета.

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

Больше не вижу доводов . И как-то это не убеждает пока

дело даже не в наладоннике, дело в том что веб админка - это возможность управления с чего угодно, лишь бы на этом "чем-то" был веб браузер! карточный дилер же не требует клиента

До сих пор не возникало необходимости.

А всё-таки: зачем?
Управление биллингом - штука не такая массовая, как гмэйл. Пользуется ограниченное число лиц только из рабочей локалки.

Просто по приоритетности задач, стоящих перед разработчиками, эта - где-то в конце.

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


я не знаком с приоритетами, т.к. более-менее подробный BGB roadmap (хотя бы TODO) нигде не засвечен и поэтому мне трудно судить

Родилось предложение по личному кабинету:
Cделайте пожалуйста аналог ActionAfterEvent, только в личном кабинете.

Тогда можно будет "декорировать" стандартные вебэкшены собственными данными в xml. Не всегда удобно писать новый Action.

Сейчас приходится делать примерно так:

Добавил в TODO

я правильно понимаю, что можно будет писать скрипты, и в xml уже что то передавать?

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Спасибо, очень круто.

skyb, да, правильно.