Технологии: LS vs XPages, и вообще куда идти...
- Автор темы lmike
- Дата начала
на другом берегу океана есть, у нас об этом единицы слышали... Вот хочу попробовать.
Столкнулся с тем, что нужно возвращать по разным критериям, разные объекты в json.
Стандартный DAS не катит, нужно все равно пересобирать в нужный вид...
Опять же, из вьюхи получаешь entry, а если во вьюхе нет, то надо дергать документ.
Так что либо rest из extLib, либо xAgent, либо веб-сервис... Ну и зачем тогда DAS... Да и SmartNSF тоже...
Просто подкупает именно возможность самому сделать нужные ресты, а не писать агент, не использовать extLib и тд
а про сравнение скорости вот
Ссылка скрыта от гостей
Но опять же, 100к доков для массовой обработки это резкость в обычном СЭД, даже в CRM, это больше в аналитике надо.
А для аналитики лучше использовать другие решения, а не на лотусе.
это да, и по перформансу - часто получением энтриса все не заканчивается..., а параллельная обработка нивелирует время на запрос (вот еще будет интересно RVE в несколько потоков посмотреть), у DAS все плохо с мультипоточностью на запись РТ, по остальному не заметил, и сделать PATCH ничем кроме DAS я не вижу возможным (кроме как писать собственную обработку)
Ну то е - фронт уже чистая нода ? И как например раскидывание по площадкам\регионам?
В чисто домине удобно - гарантированно прилетает на место и морда и связанный с ним бэк.
DAS\etc - ИМХО это для слабо связанных архитектур - когда шарятся справочники и тп. серьезный бизнес-процесс все равно делать на сервлетах\LS\ или еще чем то - которое будет обрабатывать и валидацию и контекстные ошибки и т п вещи.
Хотя на выходе - да. Тот же самый джейсон)
Не ну согласись - хрен с ним с ответов от бэка - но вот как то я не представляю как разносить по площадкам UI для ноды.
Я понимаю и знаю что ест для этого фигова туча тулзов и примочек... Но эта архитектура именно для ноды.
хотелось бы иметь результаты трансляций css\js ноды (имеется ввиду не рантайм) все в дизайне БД. пусть будет WebDav или еще что то. очень интересны use case по этом поводу.
ты думаешь, что есть сумасшедшие, которые на одной ноде, как фундаменте, строят корпоративные распределённые системы с кучей серверов для фронта?)
ну, если такие есть, то им дают кучу новых АПИ для подключения к домине, на выбор.
это, кгбэ, просто допвозможность получать инфу из ужэ существующих доминошных баз - в этом случае просто нет никакой необходимости опираться на домино,
ИМХО, монго\коуч... для этой цели лучше\проще\шустрее
хотя, домино - комбайн, а нода - только маленький кусочек предполагаемой системы, к которой надо присобачить туеву хучу тулзов, что бы получилось домино
да не - реч не о сумашедших) И вопрос более к @oshmianski наверное) Есть большая и старая система на домино. оч хорошо работает - но морда блин ((( Но там оч много уже тащится через сервисы бизнес сущности разные.
Вот и хочется используя модняцкие фреймворки обновить эту морду лица...
А бутстрап не нравицца? Включаешь тему и всё бутстрапится из встроенного...
Родное всётки
Хотя, мне лень следить за бутстрапными классам... )
...Тот же ангуляр подключается, ток в дизайнере неудобно будет писать - будет на синтаксис ругацца. Ну... внешний редактор никто не запрещал. А вход, как обычно - через икспейдж
И твои "бизнес сучности" будут доступны )
Эт так, рассуждалки
-----------------
опятжэ, жыквери использовать (если от дожо тошнит) совсем без проблем, просто надёргать поля и контролы в хэпагу из формы не гут - будет сплошной JSF, где надо и где не надо, да и встроенные виды не прокатят. Всё равно лапами писать с нуля лучше (ИМХО) и всё равно прямой вход через хэпагу, быстрей любого другого подхода в разработке под домину в домине)
----------------
ну, а "react + redux + router + material-ul, пишу в WebStorm "(с) из под ноды, как товарищ писал, это отдельная тема, к домине имеющая такое же отношение как и к монго, коучу и сиквелам разным...
Последнее редактирование:
Нет, front-end не чистая нода. По сути, node.js используется только на этапе разработки.
react + redux + router + material-ul - это все не более чем библиотеки (а-ля JQuery), которые облегчают программирование. Результатом все равно является bundle.min.js + bundle.min.css, которые засовываются в WebContent лотусовой бд.
Поэтому связывание front-end и back-end остается в ваших руках, как и было.
Ну значит в проекте большущий js с css - в котором все в куче или для каждого контекста свои bundle.min.js ?
И как кидается в WebContent - dxl или говорят WebDav там то же работает ?
css маленький в виду использования jss в 99% случаев.
js - 2.2 Mb на все приложение, но можно и разбивать на динамически загружаемые модули.
по поводу контекста не понял. что имеется в виду?
Кидается в дизайнере:
Контекст - ака динамическая погрузка js.
Ну т е руками после отладки или есть чем автоматом залить после pull request?
это можно (если слишком большой общий js) - современный JS и react это позволяют.
ручками
Но как ручками то? Т е - отладка идет вне целевой системы - или я не понял...
Совсем вне) Отладил, скомпилил бандл(ы), положил в базу(базы)
Хотя и это непонятно (лично для меня) - зачем запускать отвязанный ноде-сайт под доминой, если это можно сделать нативно их под ноды
Классический нода-разработчик ващще не знает, что такое домина - для него это абстрактная база domino-db, просто ещё один источник данных, ни чем не лучше mongo-db, к примеру)
ЗЫ нода, плюс вышеперечисленное (реакт редукс....) - абсолютно самодостаточная система, так же ,как и домина со всеми её плюшками.
Что они могут друг другу дать- большой философский вопрос
Последнее редактирование:
Попробую подробнее описать мой подход в разработке...
Есть js-проект
Он живет отдельно, совершенно ничего не зная о Domino.
При его разработке и сборке используется node.js + webpack. За данными (при разработке) все запросы проксируются webpack'ом.
domino-rs - это Domino сервер.
/develop/dev3/claimcb.nsf/api.xsp - это доминошная бд с данными (а может и без данных) и REST api.
По сути, node.js используется для поднятия тестового http сервера на localhost
ost для отладки в процессе разработки, webpack - для обновления изменений при разработке, проксирования запросов и сборки.
Какую IDE использовать - ваш выбор, хоть блокнот, все запускается из консоли. Вот так выглядит у меня в WebStorm:
Наразрабатывали, протестировали, собрали билд = bundle.min.js.
Затем вручную открываю дизайнер и импортирую билд в бд.
Все, открываем бд (на самом деле я из бд открываю index.html ресурс из WebContext) с Domino сервера. Далее работает SPA, react, redux... = front-end.
В продуктиве front-end тот же что и в девелопе, но запросы не проксируются, а берутся из того места, от куда открыли бд.
Девелоп:
Продуктив:
Еще нюанс с basic-аутентификацией: при разработке хардкодом прописываю нужные заголовки аутентификации в запросах с нужным пользователем.
Как-то так.
Есть js-проект
Он живет отдельно, совершенно ничего не зная о Domino.
При его разработке и сборке используется node.js + webpack. За данными (при разработке) все запросы проксируются webpack'ом.
domino-rs - это Domino сервер.
/develop/dev3/claimcb.nsf/api.xsp - это доминошная бд с данными (а может и без данных) и REST api.
По сути, node.js используется для поднятия тестового http сервера на localhost
ost для отладки в процессе разработки, webpack - для обновления изменений при разработке, проксирования запросов и сборки.Какую IDE использовать - ваш выбор, хоть блокнот, все запускается из консоли. Вот так выглядит у меня в WebStorm:
Наразрабатывали, протестировали, собрали билд = bundle.min.js.
Затем вручную открываю дизайнер и импортирую билд в бд.
Все, открываем бд (на самом деле я из бд открываю index.html ресурс из WebContext) с Domino сервера. Далее работает SPA, react, redux... = front-end.
В продуктиве front-end тот же что и в девелопе, но запросы не проксируются, а берутся из того места, от куда открыли бд.
Девелоп:
Продуктив:
Еще нюанс с basic-аутентификацией: при разработке хардкодом прописываю нужные заголовки аутентификации в запросах с нужным пользователем.
Как-то так.
Вложения
ачё ты нервничаешь?) хепаги не вырежут - нет у них ни решимости, ни ресурсов. Не будут развивать? Так их и не развивали 10 лет (экстлиба не в счёт) и ничего не порушилось
Упростят интеграцию с новомодностями - флаг им в корму. А вообще, они расписались в своей несостоятельности продав домину, смена вендора ничего не меняет, кроме размазывания ответственности и уменьшения финансовых рисков для Айбиэм.
ЗЫ вон @oshmianski пишет под домину на реакте и людям нравится. и без всякой интеграции ноды в домину, а ведь это, ну ни в каком месте, не NodeApp, приминительно к домине.
Не понимаю я их (HCL) "стратегию"(
Обучение наступательной кибербезопасности в игровой форме. Начать игру!