Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нем неправильно. Необходимо обновить браузер или попробовать использовать другой.
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
фраза непонятна
когда пишешь какой-то интерфейс, то в едином месте описываешь и фронт и бэк(ну это если мы говорим про фрэймворки java/scala). В Domino это происходит "коряво", т.к. все нужно описывать в разных местах и корректировать потом немного затруднительно. Про работу сервлетов вообще молчу, т.к. их надо вообще предварительно выкладывать на сервер.
ковыряя исходники extlib - видел что они используют сервлеты, но не было времени разбираться как они это сделали(хотя могу и ошибаться, т.к. это было уже почти год назад)
тестовые примеры написанные на SproutCore или на Cappuccino я внедрял в лотус - копированием уже готовых компонент в саму базу и редактированием 1 форму(index.html). Единственным недостатком, который не заработал "слету" это было как раз сервлеты. Есть json-rpc, есть RestDataSource в SmartGWT, но времени как это прикрутить в лотус у меня не было Интертраст для своего нового фронта на GWT сделали такую интеграцию, но молчат как партизаны
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->когда пишешь какой-то интерфейс, то в едином месте описываешь и фронт и бэк<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
В XPD так и есть. Разумеется, если пользоваться в апи готовыми компонентами, то о фронте не задумываешься. Если сам разрабатываешь компонент для XPD, то в одном месте и фронт и бек.
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->Про работу сервлетов вообще молчу, т.к. их надо вообще предварительно выкладывать на сервер.<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
В XPD это просто. Вся работа уже сделана. Разработана плагиновая система. Свои компоненты и сервлеты помещаются на файловом уровне в определенную папку и когда вы что-то в них обновляете, то по нажатию одной кнопки из админки все внешние модули перезатягиваются и движок начинает работать уже с обновленным кодом без перезагрузки сервера и кода движка.
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->95% из описанного - доступно и при стандартном подходе. Остальное - при некотором напряге<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Этот "некоторый напряг" может вылиться в годы разработки .
Например, стандартная задача для практически любой веб-страницы: по клиентскому событию (нажатие на кнопку, потеря фокуса, нажатие клавиши и т.п.) необходимо поменять содержимое для разрозненных нескольких дом-контейнеров браузера. Причем новое содержимое разумеется тоже может быть интерактивным. Для стандартного XPages такая задача решается только полным обновлением всей веб-страницы. Наш движок все помеченные компоненты для обновления (либо созданные новые/удаленные старые) в одном веб-ответе отдает за один "присест" и раскладывает по своим местам, сохраняя XPage/XPD функциональность.
Или штатный для XPD драгэнддроп: в беке помечаете компоненты, которые можно тянуть и помечаете контейнеры куда можно кидать, подписываетесь на события (все в том же беке) и все работает.
Не замечали в стандартном XPages, что происходит, если у вас есть 2 серверных обработчика, которые могут триггится практически одновременно (как пример клик на кнопку с потерей фокуса у поля/событие изменения поля). И в этом случае отработает на XPages- сервере только один обработчик, причем заведомо не известно какой. Второй проигнорируется. В XPD эти задачи решены на уровне своей платформы.
Или синхронизация полей нотес-документов, выполняемая фоновыми потоками (чтобы не замедлять ответы браузерам).
Или такая мелочь, как аплоад за раз нескольких файлов. В XPages не пробовали это сделать?
Не пробовали в стандартном XPages поработать с нотес-сессией/контекстом в созданных вашем кодом потоках? Используя апи с движком XPD вы работаете с нотес-ресурсами одинаково как в основном потоке, так и в дополнительных.
А такие готовые компоненты как:
- табконтейнер с ленивой загрузкой контента вкладок и полным контролем событий переключения по вкладкам
- бордер контейнер с тягабельными/схлопываемыми зонами
- ленты, представления по нотес-представлениям с автоподгрузкой, нормальной поддержкой тотал-колонок, с возможностью разукрашки строк представления, колонок, да и вообще возможность кастомно формировать контент ячейки представления
- простые контейнеры с ленивой загрузкой
- компонент просмотра контента вложений, нормального аплоада вложений
- секция (с ленивой загрузкой), дерево (с ленивой загрузкой), компонент работы с картинками, нормальные диалоги и пиклисты с автоподгрузкой, компоненты просмотра данных из реляционок с автоподгрузкой, поиском, сортировкой
...
и все это "only ajax" и "refresh only needed"
Перечислять на самом деле можно очень долго, чего не умеет или умеет, но неприемлемо коряво стандартный XPages, особенно когда проект большой и работает с большим количеством баз данных и веб-страниц.
...необходимо поменять содержимое для разрозненных нескольких дом-контейнеров браузера...Для стандартного XPages такая задача решается только полным обновлением всей веб-страницы.
Ничего подобного. Стартовая страница содержит только один контейнер (div) в который я гружу (или добавляю) любой контент (страницы, кастомконтролы, отдельные компоненты). Загружаемые страницы могут быть сколь угодно сложными, в том числе, с вложенным контентом (теми-же контейнерами в которые гружу что надо и когда надо). И обхожусь - PartialRefresh. Так что только одна страница (другие - только по необходимость, если логика диктует)
Или штатный для XPD драгэнддроп: в беке помечаете компоненты, которые можно тянуть и помечаете контейнеры куда можно кидать, подписываетесь на события (все в том же беке) и все работает.
Это замечательно, только логика дропа может быть произвольной (например: только "для показать", или обновить инфу на сервере). В совсем общем случае - все равно кодить.
Не замечали в стандартном XPages, что происходит, если у вас есть 2 серверных обработчика, которые могут триггится практически одновременно (как пример клик на кнопку с потерей фокуса у поля/событие изменения поля). И в этом случае отработает на XPages- сервере только один обработчик, причем заведомо не известно какой. Второй проигнорируется. В XPD эти задачи решены на уровне своей платформы.
Компоненты можно напридумывать сколь угодно полезные и красивые, спору нет. Только на все случаи все равно не заготовишь. Я и из стандартного-то комплекта использую далеко не все . Тут каждому - своё.
Если в стандартных нотусах - я ветеран (v3), то в хепагах - начинашка. Поэтому, может быть со временем, мнение изменится.
P.S.
"only ajax" и "refresh only needed" я так и поступаю, несмотря на практически нулевой опыт. "неприемлемо коряво стандартный XPages" коряв он, в первую очередь, интерфейсно, а не идеологически.
Даже не это главное. Геморрой - это практическое отсутствие нормальной документации. JSF чудовищно мощен и гибок. И если-бы разрабы не выдавливали из себя информацию по каплям равномерно распределяя её по инету все было-бы по другому.
А вообще Вам респект за попытку исправить ситуацию. Но это похоже не для меня, хоть я и не причисляю себя к любителям кодить сайты в блокноте.
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->Ничего подобного. Стартовая страница содержит только один контейнер (div) в который я гружу (или добавляю) любой контент (страницы, кастомконтролы, отдельные компоненты). Загружаемые страницы могут быть сколь угодно сложными, в том числе, с вложенным контентом (теми-же контейнерами в которые гружу что надо и когда надо). И обхожусь - PartialRefresh.<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Наверное вы не поняли мое высказывание по данному поводу.
Имеется в виду ситуация, например, когда у вас уже есть сколь угодно сложная страница. В вашем случае это div как контейнер с как-то сгенерированными внутренностями.
И например у вас есть на этой странице кнопка, которая должна изменить контент 2-х непересекающихся домэлементов (т.е. соответствующих им бекендовых сущностей).
Из доступного "арсенала" инструментов XPages у вас есть 2 способа: PartialRefresh и FullUpdate.
Если вы примените первый инструмент к двум компонентам, то обновится в браузере последний из них, первый останется как есть необновленный.
FullUpdate же обновит все, включая и то, что не менялось.
И еще пример: у вас есть страница с контейнером с двумя компонентами. По кнопке вам нужно добавить новый компонент, так, чтобы стало 3.
Эту задачу XPages может решить только применив PartialRefresh к контейнеру целиком. Но при этом и уйдет контент двух компонентов, которые не менялись.
В XPages Dynamic же все просто: по кнопке создаете, удаляете, изменяете любые компоненты в беке. У каждого из них вызываете метод refresh и только они уйдут в браузер не зависимо от того, как они расположены друг относительно друга и рутового элемента страницы.
Пример, когда эта особенность XPages может негативно отразиться в приложении.
Например есть задача автоматически сохранять изменения ui-полей в нотес-документе.
Т.е. есть событие onchange ui-поля, на которое реагирует серверный обработчик.
И представьте, что есть у вас на той же странице кнопка с серверным обработчиком.
Теперь, если вы в поле что-то поменяете и не выходя из поля нажмете на ui-кнопку, то серверный обработчик отработает либо кнопки либо поля, но насколько я помню когда мы тестили, что сработает скорее кнопка.
Т.е. событие изменения поля на сервере не отработает и новое значение поля не сохраниться в этот момент.
Есть такое наблюдение.
Но это относится не xpages, особенности есть везде, а к стилю программирования.
Я начинал "когда ЭВМ были большие", и всё программирование было на бумаге. И было несколько простых правил, без которых результат не получить никогда. "Набивка" программы - пиши заявку, "прогон" - пиши заявку. В набивку надо отдавать только рабочий код, иначе не закончишь никогда.
Программируй только логически завершенные блоки которые можешь осмыслить целиком.
Чем блок короче - тем лучше.
Собирай программу только из проверенных блоков.
Пиши только то, что знаешь наверняка.
Написал - осмысли, что произойдет.
Поймал ошибку и исправил - не запоминай - запиши.
Как то так.
Поэтому проблема, чаще всего возникает однократно.
Не напрягает.
Объектное программирование толкает на другой стиль. Сборка из шаблонов вкупе с методом проб и ошибок дают, порой, плохие результаты.
Рассмотрим два варианта лицензирования, в компании 100 человек (например):
1.Толстый клиент Lotus (именные лицензии): 100 лицензий * 150$ = 15 000$
2.XPD, все работает в вебе (конкурентные лицензии): 30 лицензий * 100$ = 3 000$
XPD - возможностей больше, стоимость владения ниже…
Офлайн не актуально + куча проблем (конфликты/безопасность/трафик…), возможность использования современных подходов к управлению процессами (BPMN 2.0) – вообще весьма сомнительна. Меняя один документ приходиться также менять кучу связей которые могут быть где угодно. Если даже каждый пользователь реплицирует себе всю систему на локал – это не решает всех проблем в общем случае.
Недавно проводили презентацию XPD у заказчика по GPRS (ноут подключенный через мобилу…). IT служба заказчика не смогла быстро настроить безопасный доступ к внутренней WIFI сети банка, пришлось выкручиваться. Быстродействие приятно удивило заказчика (мы сами были в шоке).
Возможность быстро работать из любого места (офис/дом/командировка/курорт…) + экономия на лицензировании + новые возможности, которые недоступны из толстого клиента.
Рассмотрим два варианта лицензирования, в компании 100 человек (например):
1.Толстый клиент Lotus (именные лицензии): 100 лицензий * 150$ = 15 000$
2.XPD, все работает в вебе (конкурентные лицензии): 30 лицензий * 100$ = 3 000$
XPD - возможностей больше, стоимость владения ниже…
Вы же сами акцентируете тонкий клиент (еще + сервер)
Аренда Application Server Domino на Амазоне - примерно 150 баксов в месяц (со всеми пирогами и даже больше - 200), если только хочу "прогнать" проект, плюс мой гемор. Деньги вообще никакие.
Все пошло - взял свою лицу ~ 4500.
Коннекшины бесплатно.
Несоизмеримо.
Но это лирика.
Если заказчик уже на домине - о закупке клиентов речь не идет. XPD добавляет траты, а зачем ему тратить при наличии команды.
Если нет - можно показать преимущество, но сервер то все равно брать.
Плюс бизнес противоречие: Вы ориентируетесь на крупного клиента, который никогда не отдаст IT на аутсорс на 100% и все равно наймет команду. А если наймет - заставит делать все без лишних трат. Значит для продаж - нужен инсайд. Свободный рынок прослеживается слабо тем более, что имя надо заработать.
Только возможность подключиться к системе стоит всего в 1,5 раза дешевле того, что можно потрогать руками, а в случае AS вообще даром. Не логично.
По цене Вы ставите себя практически на одну ступень с IBM - это очень сложно объяснить заказчику.
Хотя "Облака" модная тема сейчас. Какие-то пенки снять можно.
Если речь не о домине - это не то место для обсуждения.
...Эту задачу XPages может решить только применив PartialRefresh к контейнеру целиком. Но при этом и уйдет контент двух компонентов, которые не менялись...
Вы ошибаетесь. У меня проблем с этим нет, контент никуда не девается (может быть пока ).
Почти полная динамика. Могу полностью заменить контент в любом контейнере. Могу добавить в конец. Удалить\заменить компонент по ID без танцев с бубном не могу. Подскажете - буду благодарен.
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->Вы ошибаетесь. У меня проблем с этим нет, контент никуда не девается (может быть пока ).<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Видимо вы опять не поняли. "Уйдет" - не означает пропадет или исчезнет. Уйдет - в смысле уйдет с сервера в браузер, т.е. с сервера прийдет и контент двух компонентов, которые не менялись, а это не целесообразно.
Обратите внимание как вы добавляете В беке добавили в конец. Это разумеется просто. А теперь попробуйте только что добавленному компоненту в беке сделать PartialRefresh И скажите что у вас получилось.
Обратите внимание, опять же, не родителю нового компонента сделать PartialRefresh (т.к. это приведет к тому, что придет в браузер контент родителя со всеми потрохами).
На примере: у вас есть итерационно выводимые данные, например из реляционной таблицы/представления. Вы вывели буфер, например данные из 20 строк, эта информация интерфейсно лежит в каком-то контейнере.
А теперь по скроллу нужно догрузить к уже имеющимся 20 строкам еще 10, а потом еще 10 и т.д. На каждом этапе как вы будете их с помощью XPages частично обновлять в браузер не трогая общий контейнер, который постепенно увеличивается в размерах за счет добавления новых строк данных. Скорее всего решение только одно: только PartialRefresh к общему контейнеру. Т.е. на каждой итерации придется все больше и больше присылать данные, которые и так уже присутствуют в браузере. Вы можете сказать, что можно применить Repeat контролы. Но они могут решить только небольшую часть задач. Например, они не могут добавлять данные всередину и с добавляемыми компонентами очень сложно потом работать. Например, если реализовываете функционал ленты.
насколько мне известно JSF сервер формирует xml файл при первом обращении, при обновлении сервер запоминает текущее состояние пользователя, модифицирует и заново отправляет пользователю(либо часть, либо полностью)
Какого объема эти файлы у вас формируются?
в сэд-е простых форм не бывает(по сути это одно окно будет, куда будет стекаться вся информация не только по сэд, но и по другим системам), поэтому размер этих xml файлов, которые сервер будет у себя хранить в памяти критичен, т.к. при 300-400 одновременно активных пользователях и размером xml допустим в 10 метров сервер уже дополнительно будет требовать 3-4 гига памяти только на обработку этих файлов
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->в сэд-е простых форм не бывает(по сути это одно окно будет, куда будет стекаться вся информация не только по сэд, но и по другим системам), поэтому размер этих xml файлов, которые сервер будет у себя хранить в памяти критичен, т.к. при 300-400 одновременно активных пользователях и размером xml допустим в 10 метров сервер уже дополнительно будет требовать 3-4 гига памяти только на обработку этих файлов<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Вы правы насчет хранения состояния пользователя, но основной (95%) расход памяти приходится не на XML-конфигурации, а на рантайм объекты, созданные по XML-конфигурациям при рендеринге каждой страницы. Т.е. для того, чтобы XPD-движок сформировал HTML-страницу, в беке практически для каждого домэлемента создается соответствующий ему объект, унаследованный от javax.faces.component.UIComponent. Это самый низкий уровень абстракции XPD. Кроме того, есть еще 2 уровня абстракции: один для апи, второй для собственной среды разработки. Все уровни абстракции инкапсулируют объекты нижних уровней абстракции. Расход памяти очень большой, но и быстродействие колосальное. Для контроля и управления расходом памяти в XPages Dynamic разработаны механизмы, очищающие ссылки на все объекты, которые были созданы для уже неактуальных страниц. Есть гибкая система настроек такого механизма. Для указанного вами количества одновременно работающих пользователей я думаю что бы потребовалось порядка 16-64 гиг оперативной памяти в зависимости от настроенного срока актуальности страницы и периода очистки объектов. Для аппаратных средств системы корпоративного масштаба это не должно стать проблемой в виду относительной дешевизны оперативной памяти сервера.
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->Если заказчик уже на домине - о закупке клиентов речь не идет.<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Идет, если решение нужно масштабировать или толстый клиент не справляется с современными задачами бизнеса, или нет желания обновлять старое железо, которое тормозит у пользователей (благо через браузер XPD работает очень быстро даже на старых машинах, в отличии от толстого клиента) + на обслуживание толстого клиента нужно больше ресурсов (время/люди), ну или просто босс хочет работать в системе с планшета/мобилы
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->XPD добавляет траты, а зачем ему тратить при наличии команды.<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Ну, если команда работает бесплатно или сидит без дела + имеет должную квалификацию и опыт, то конечно за год с небольшим продукт сделают (возможно!), но все же стоит посчитать затраты:
(Минимум!)
2 бэк программера + 1 фронт программер + руководитель проекта/идеолог/постановщик + дизайнер/верстальщик/css + тестер.
По скромному, общий фонд зп 10 000$ * 12 мес. = 120 000$
А потом этот самопис нужно поддерживать + развивать (опять таки затратно) + риски для бизнеса.
Использование тиражного решения - быстрый результат за меньшие деньги и с минимальными рисками.
Эдак можно и свой MS Office написать, зачем тратить деньги на лицензирование (кстати очень большие), ну а чо, команда то есть
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->Плюс бизнес противоречие: Вы ориентируетесь на крупного клиента, который никогда не отдаст IT на аутсорс на 100% и все равно наймет команду.<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
А зачем на 100%, пусть частично, в любом случае бизнесу это выгодно. Вот, например, крупные сети (АЗС/Аптечные холдинги и пр.) отдают 1C (кстати на все 100%) и экономят кучу денег. Своя команда конечно нужна, но в меньшем составе, опять таки выгодно.
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->Значит для продаж - нужен инсайд. Свободный рынок прослеживается слабо тем более, что имя надо заработать.<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Верно, рынок нужен и он есть. Домино имеет не малое количество инсталляций (не только СНГ) и решений на нем написано достаточно много, но вот качественный веб - большая редкость. Потребность в простом инструменте для быстрого вывода решений в веб и на мобильники реально есть (проводили маркетинговые исследования).
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->Только возможность подключиться к системе стоит всего в 1,5 раза дешевле того, что можно потрогать руками, а в случае AS вообще даром. Не логично.<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Lotus Notes порой и в локалке не быстр(!), юзать его из публичного облака - плохая идея (филиальная сеть, канал в среднем 2 Mb, на каннале до 30 человек...).
Можно конечно в наши дни развивать тему децентрализованного управления (много серверов/реплики), но в этом случае возвращаемся в 2000 год + опять таки затратно (лицензии/люди/оборудование).
</td> [/tr] </table> </td> [/tr] </table> </td> [/tr] </table> <table border="0" cellpadding="0" cellspacing="0" width="100%"> [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-left.gif')"></td> <td class="vbquotemain" width="100%" valign="top"></td> <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quoting-right.gif')"></td> [/tr] [tr] <td class="vbquote" width="10" style="background-image: url('style_images/ckr/quotes/quot-left-bg.gif')"></td> <td class="vbquotemain" width="100%" valign="top"><!--QuoteEBegin-->По цене Вы ставите себя практически на одну ступень с IBM - это очень сложно объяснить заказчику.
Хотя "Облака" модная тема сейчас. Какие-то пенки снять можно.<!--QuoteEnd--></td> [/tr] [tr] [/tr] </table> </td> [/tr] </table>
<!--QuoteEEnd-->
Облака, откуда они взялись, возможно ветром надуло.
Важно(!) XPD - конкурентные лицензии (уже писалось ранее).
Например: если систему используют 100 сотрудников, но одновременно с системой работают не более 30-ти человек, то приобрести необходимо всего 30-ть лицензий, подробнее тут
Ссылка скрыта от гостей
Возможно, я не ясно объясняю, попробую иначе, для легального использования нужно:
1. IBM XWork Server 1070$ в год - ограничений по количеству пользователей/подключений НЕТ!
2. XPD - одна конкурентная лицензия в среднем заменяет три именные Lotus Notes.
Считаем:
1 XPD лицензия = 100$
3 лицензии Lotus Notes = 450$ (на самом деле 178$*3)
Cервер в расчет не берем, он в обоих случаях нужен (облака/ямы...).
100$ < 534$
Резюмирую:
XPD в 5 раз дешевле Lotus Notes + больше возможностей + меньше требования к рабочим станциям.
+ новые (современные!) приложения можно создавать/настраивать без знаний программирования (натягивание мышкой и установка галочек).
Думаю что это заказчику объяснить не сложно
З.Ы.
Предлагаю завершить лирические отступления ибо время дорого.
Никоим образом никого не хотел зацепить, если есть вопросы задавайте, если не ком. тайна - отвечу.
Так-же не хочу Вас зацепить.
Но Вы продаете по-существу "воздух".
Поясню:
Есть два основных объекта продажи:
- продукт (то, что можно потрогать - вещь, инструмент и д.т.)
- услуга (то, что Вы не можете или не хотите сделать и предлагаете сделать другим)
Вы же выбираете третий, самый, на мой взгляд, нечестный - возможность чем-либо воспользоваться.
К нему относятся, например, объекты авторского права, возможность посетить фитнес-центр и т.п.
К подобному типу продаж у меня отношение крайне отрицательное.
Я бы принял, если-бы вы брали плату, например, за каждый факт подключения к системе для её использования, за время, проведенное в среде, за использование каких-то существенных свойств в определённом объёме и т.д.
Т.е. брали плату за услугу, если не ходите продавать продукт. Если Вы понимаете о чем я говорю.
Я был видимо прав, когда предположил, что вам не дают спать лавры Нуралиева.
Но 1С (как и IBM, Microsoft, Adobe и т.д. и т.п.) продает инструмент, а не возможность его использовать.
Дайте обойдемся без домыслов и вымыслов, мы продаем:
1.Продукт/инструмент, стоимость одной конкурентной лицензии продукта/инструмента – 100$ (да простят меня коллеги что я повторяюсь повторяюсь)
2.Услуги – если заказчик пожелает.
Других вариантов у нас нет (пока) и я про другие варианты не писал.
Не перекручивайте пожалуйста.
Вот вам похожая система лицензирования (воздушная с вашей точки зрения), ознакомьтесь для общего развития.
Ссылка скрыта от гостей
Кстати вот еще будет полезно знать
Ссылка скрыта от гостей
Но 1С (как и IBM, Microsoft, Adobe и т.д. и т.п.) продает инструмент, а не возможность его использовать.
Вы ошибаетесь, IBM XWork Server и Microsoft Action Pack лицензируются по подписке - НЕ продаются!
З.Ы.
Кстати, описанный вами вариант № 3 (тот который самый не честный) это облако, но мы в облаке пока не работаем.
Теперь вы знаете что воздух это хорошо
странное обсуждение...
предлагается некий модуль к домине и в облаке (я правильно понимаю?)
пока будут проталкивать веб-онли - нет замены LDN - точка
лицензии - если выбрали домину - уже выше сказано alexas
есть и развиваются различные плагины (ExtLib например) и они (в отличии от предлагаемого) работают на клиенте
Спору нет. Еще одна технология, конечно же плюс. и она на самом деле не размывает общий кейс продукта.
И даже модель лицензирования наверное имеет право на жизнь. Но - по воле случая столкнулся с неожиданным может быть применением XWork в ФЦП - медицине например.
На исключительную неоднозначность задач, которая изобилует данная отрасль замечательно ложится парадигма разработки для Домино - в разы эффективнее чем аналогичные на других платформах. Уже проверено.
Сейчас имеются инсталляции с тысячами пользователей Web приложений на Домино.
И тут предлагаемая модель и стоимость одной лицензии имеет риски в плане доверия федеральных и муниципальных представителей к итоговой стоимости владения данной системы. Ибо именно им отвечать за уровень доступности сервиса в периоды сезонных эпидемий или доступности сервиса при авариях в ЖКХ - ну понятно о чем я В ту же кассу и расходы памяти на авторизованных пользователей.
Как справедливо заметил коллега, очевидной областью применения данной технологии больше подходит корпоративный рынок, с их устоявшимся ландшафтом.
И сравнение с толстым клиентом тут не совсем корректно, поскольку толстый клиент сам по себе является средой исполнения, самодостаточной для функционирования на ПК клиента, не говоря об уровне интеграции со всем существующим окружением (1С, поток. сканирование, вызов банального батника и т.п.). Ну а быстрая работа на слабых компьютерах уж совсем вызывает улыбку... Т.е. Вы гарантируете, что на 256 памяти хром 30.х не захлебнется в свопе при мало мальской JS активности?
Тем не менее сама по себе технология интересна и показывает как потенциал стека JSF на домино, так и то что домино еще ого-го!!
Насчет лицензирования, полностью с вами согласен, оно не подходит для не прогнозируемых пиковых нагрузок большого количества авторизованных пользователей. Задача решается безлимитной лицензией или путем проведения переговоров с разработчиком (такие всплески можно учесть).
Насчет оперативки - мы уделяем очень много внимания эффективному использованию памяти. Результаты замеров показывают, что на одного активного пользователя требуется менее 1 мегабайта оперативки - это если пользователь очень(!) активный.
Если предположить что настала пиковая ситуация и в систему одновременно вошли около 1 000 дополнительных и при этом очень активных пользователей, то на этот случай на сервере должен быть резерв памяти около 1 гигабайта. Если же, так получилось, что все резервы памяти исчерпаны, то самые старые сессии закрываются. Как только пользователь проявляет активность, то сессия опять таки открывается.
…XPD это не модуль в облаке и не аналог ExtLib, о том что это и для чего уже писалось не раз, на официальном сайте это также написано белым по красному/оранжевому/зеленому -
Ссылка скрыта от гостей
Ну а быстрая работа на слабых компьютерах уж совсем вызывает улыбку... Т.е. Вы гарантируете, что на 256 памяти хром 30.х не захлебнется в свопе при мало мальской JS активности?
Подвернулся очень старый комп, ему больше 13 лет, раритет - 600 МГц / 256 память / 40 гиг винчестер. Решили проверить – как именно на таком железе работает XPD.
Задача теста не демонстрация продукта, а лишь проверка его работоспособности.
Платформа XPages Dynamic подросла - новые версии, новые возможности, и конечно новые планы.
Если Вы периодически сталкиваетесь с приложениями Lotus Notes, то скорее всего Вам будет интересно посмотреть короткий видеоролик.
В видео мы демонстрируем, как можно быстро вывести существующие приложения Lotus Notes в веб.
Для примера мы взяли бизнес-приложение "база знаний" из СЭД iTs-Office (построена на IBM Lotus Notes/Domino) и буквально за 11 минут создали веб-интерфейс для этой базы с помощью Xpages Dynmaic.
На данном сайте используются cookie-файлы, чтобы персонализировать контент и сохранить Ваш вход в систему, если Вы зарегистрируетесь.
Продолжая использовать этот сайт, Вы соглашаетесь на использование наших cookie-файлов.
