Aven писал(а):вот логичное разделение кода интерфейса пользователя от низкоуровневой работы с тем же диалпланом - неободимо. Но такое даже в нелюбимом вами FreePBX есть.
странно, чуть выше кто то от Вашего имени написал, что в FreePBX нет гуя пользовательского
ddkprog писал(а):смысл не в кучи libasterisk
смысл в том что бы автор правильно и логически мыслил, и наличие некоего libasterisk,
показатель того, что автор таки умеет мыслить логически и вытягивать +100500 опций в одну логическу концепту под названием "хочу_зашибись_0" "хочу_зашибись_1" "хочу_зашибись_2"
это есть гуд для конечного пользователя, а не для админа, к которым себя относят 99% местного контингента. Попытка пересадить админа на такой гуй ни к чему хорошему не приведет ибо админ пользующийся гуем яля freepbx будет по инерции искать нужную ему 100500 галочку и не найдя скажет, что это гуано. Попытка написать гуй 'Такой же как FreePBX но быстрее/красивие' - провальна по причине того, что писатель всегда будет выступать в роли догоняющего.
Последний раз редактировалось gosha 06 фев 2012, 13:59, всего редактировалось 1 раз.
gosha писал(а): Попытка пересадить админа на такой гуй ни к чему хорошему не приведет ибо админ пользующийся гуем яля freepbx будет по инерции искать нужную ему 100500 галочку и не найдя скажет, что это гуано.
Что мы сопсно и наблюдаем в этом животрепещщущем топике.
gosha писал(а):Попытка написать гуй 'Такой же как FreePBX но быстрее/красивие' - провальна по причине того, что писатель всегда будет выступать в роли догоняющего.
+1000
Точность формулировок - истинный показатель мышления и абсолютная ценность.
Вижу началось то, что и было нужно - активная дискуссия и обсуждение.
Постараюсь более подробно описать то, над чем мы сейчас работаем.
И так, первое что нам не нравится в FreePBX это сложность внесения изменений. Я не говорю о быдлокоде (которого там достаточно), а о том что внося изменения в какой либо модуль, вы теряете совместимость, а когда количество модулей и клиентов растет, начинается дикий хаос.
Второе, это когда клиенту нужен был ваш специфичный модуль, а позже стал не нужен. И человек который его переписывал заболел, уехал работать за границу, или попросту пропал. Тогда приходится новому специалисту разбираться со всеми предыдущими хаками и доработками, а это человеко часы, а это деньги. Ведь намного проще было бы просто с помощью одной кнопки отключить все изменения и вернутся к стандартному функционалу модуля. Именно для этого нами закладывается "модульно-плагинная" структура, то есть внесение изменений в функционал какого либо модуля можно будет совершать посредством плагинов для этого модуля.
Третье, это то, что при написании модулей, нам совсем не хочется работать напрямую с формами, производить их валидацию, думать о их html коде и о правах доступа к этому модулю. Пускай всем этим занимается фреймфорк, а разработчик модуля должен сосредоточится на основном - внесении данных полученных от пользователя в диалплан.
По сути, то что мы сейчас делаем является расширяемым интерфейсом для админа и пользователя (кто знаком с django, могу сказать что делается по подобию встроенной админки в данный фреймфорк).
Касательно управления диалпланом, то здесь к сожалению есть мало просторов для подвигов. Я о том что создание универсального фреймворка который будет сам генерить нужный диалплан практически нереально (кому либо все равно не понравится тот или иной алгоритм).
Функционал который мы хотим от генератора диалплана:
- возможность хранить диалплан в файлах, RealTime Static, Realtime по желанию пользователя, и при разработке модуля не задумываться от б этом.
- возможность писать диалплан на языке диалплана. По мимо возможности написания диалплана средствами ООП, мы закладываем возможность парсинга уже готовых кусков контекста (для знакомых с django - работу с данными заготовками можно будет производить средствами шаблонизатора django).
P.S. На данный форум я обратился не для того что бы уважаемое комьюнити сказало что и как нам писать, а что бы поделилось своим наболевшим, дабы заложить возможность избежать этого в нашем продукте.
Последний раз редактировалось Vetal_krot 06 фев 2012, 15:26, всего редактировалось 1 раз.
А смысл делиться наболевшим? Чтобы вы это реализовали в своем продукте и воспользовались коммерческими преимуществами?
Как я уже писал, проект Open Source. Никакими коммерческими преимуществами мы не собираемся пользоваться. Зарабатывать будет только на поддержке и написании модулей под заказ.
Такую бизнес-модель уже вовсю эксплуатируют евреи - Schmooze Corp, пишут коммерческие и opensource модули к FreePBX. И ничего, справляются в хаосе, не утонули.
Посмотрите как выглядит версия 2.10
О наболевшем. Просто бесит когда приходят револючионеры и поют "Мы наш, мы новый мир построим..."
Если честно, код ветки 2.10 и был последней каплей которая сподвигла нас на написание своего продукта.
Из всех осмотренных нами гуи, которые существуют на сей день, по нашему мнению, концептуально наиболее правильно реализован BlueBox. Но проект уже достаточно долгое время находится в непонятном состоянии, да и наших ребят не удалось уговорить развивать его.
О наболевшем. Просто бесит когда приходят револючионеры и поют "Мы наш, мы новый мир построим..."
Я такого не говорил, а высказал что нам не нравится в том что есть, и как мы намерены это решить. Я прекрасно понимаю что то, что мы делаем не лишено изъянов. Но все же, почему не попытаться?
Господа, а мне все-таки кажется что надо подходить к обсуждению не с точки зрения использования фреймворков, технологий, патчей, модулей, а просто внешнего вида. Ибо пользователь/ленивый одмин видит только веб-страничку, и ему глубоко побоку, как оно реализовано. Главное, чтобы работало хорошо. А то все ушли в частности.
ГУИ мечты - это простой и работающий. И для которого не надо читать 100500 тонн литературы. Так уж действительно вим и консоль проще освоить.
