Технологии: LS vs XPages, и вообще куда идти...

[lmike]

Имхо, полезное из всего предложенного - DQL

оно без klehmann/domino-jna не сильно интересно

 

[VladSh]

яаще всего я код форм выносил с либы и агенты, если формы "умрут" переписывать много не будет нужно

То понятно. Но всё равно очень много всего. Ожидается, что под новым клиентом всё (ну или почти всё), что связано с формами заработает. У нас и так думают, покупать ли снова поддержку (за 3 последние года, что не платили, сэкономили кучу денег)... а если оно не заработает, то вопрос автоматом снимется с повестки дня, т.к. и так много людей против того, чтобы оставаться на Lotus.

 

[lmike]

т.к. и так много людей против того, чтобы оставаться на Lotus.

тут может быть стратегическая ошибка, если "много людей" не умеют в ОСС или считают чангу + ШП чем-то дешевле/удобнее
у "нас" глобально (не трогая локльные решения) перешли на МСО365 с шариком и прочими свистоперделками, сказать что это мрак - это будет мягко, "все" как лоскутное одеяло, сшитое гнилыми нитками

 

[alexas1]

и еще меня смутило View must have only Select @All as its selection criteria

это же логично - SELECT вьюшки, по сути, переносится в DQL

ограничением набора вьюшек

почему? вьюшек может быть скока хошь, ограничение в значениях в колонке - ток значение поля (напрямую или fieldname {суть значение поля}, как результат вычисления собаки). Вроде так.

Ожидается, что под новым клиентом всё (ну или почти всё), что связано с формами заработает.

конечно заработает, всё что раньше работало в бейсике)

 

[alexas1]

по сути, новый вендор предлагает:
1) использовать Domino только как хранилище
2) вся бизнес-логика должна уйти в промежуточное node.js-серверное приложение
3) UI - react, angular....
4) аутентификация - сервис IAM - еще одно промежуточное node.js-серверное приложение, реализующее парадигму OAuth2.

Получаем такой список работающих приложений:
1) Domino-сервер
2) node.js IAM сервис
3) node.js сервис обслуживающий бизнес-логику пользовательского приложения, лазающий за данными в Domino-сервер

чёта очень жёстко))
это привлечение новой клиентуры, которая молется на ноду и совсем не врубается в логику Домино (и принципиально не хочет врубацца)
вот им и дают инструмент, доступный для их понимания - ВСЕ довески базируются на старом нотусёвом АПИ

 

[VladSh]

lmike
У нас глобально постепенно переводят все АС на стек Postgree/Mongo + Redis + ES + angular. Опыт хоть медленно, но постепенно набирается. Шариковость в плане документооборота рассматривается, но не в фаворитах.

 

[lmike]

почему? вьюшек может быть скока хошь

я имел в виду ограничение в виде указания (а не усечение ф-ционала)

Identifier

is
SummaryField | ‘View or folder name’.Columnname | @function

но тайный смысл использования нескольких вьюшек, в контексте ограничения формулы отбора ускользает

 

[alexas1]

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

быстродействие жЭ
на каждый query (или группу однотипных) - своя вьюшка: колво колонок имеет смысл иметь равным колву полей, используемых в квери, т.к. быстродействие пропорционально объёму индекса, как не крути
плюс, допустимым ограничением колва доков в коллекции отбора, предполагая размещение "нужных" доков вверху вьюшки (напр. при участии в отборе диапазона дат), быстродействие так же увеличится

 

[lmike]

на каждый query (или группу однотипных) - своя вьюшка: колво колонок имеет смысл иметь равным колву полей, используемых в квери, т.к. быстродействие пропорционально объёму индекса, как не крути

этож ППЦ скока БД будет занимать, если у каждой вьюшки все доки БД и отличие только индекса и колонок

 

[alexas1]

этож ППЦ скока БД будет занимать, если у каждой вьюшки все доки БД и отличие только индекса и колонок

Угу
и DQL, отнюдь, не полный аналог SQL SELECT, т.к. нормальные люди, в сиквеле, делают запросы из таблиц с уже отфильтрованными в них данными, а не по всей базе, за редким исключением
придётся индусам давать возможность полноценного селекта в вьюшках, иначе их не поймут)
т.е. пока это, фактически, dbSearch, ток по индексу вьюшки и с другим синтаксисом

 

[rinsk]

Пока в этом DQL не будет реализации запросов по нескольким БД, имхо практического смысла в этом мало.

 

[oshmianski]

proton - задачка Domino для обслуживания запросов от domino-db либы (не понял только по какому протоколу, судя по всему http\https).

дополню. протокол таки gRPC.

Ссылка скрыта от гостей

The new domino-db Node module uses the gRPC protocol to connect to Proton which provides a very efficient high-performance connection to Domino. It is independent of the HTTP stack. You do not need to be running the HTTP task on Domino at all to use Proton.

и вот еще показательное

They are saying you can access and extend Domino apps and data using Node.js, so Node.js becomes another strategic development stack to sit alongside the existing web solutions, Web Forms, XPages, etc. Node.js is popular with non-Domino developers and CIOs/CTOs so this helps Domino reach a new audience. It’s a parallel development approach to XPages and the HTTP stack.

т.е. предлагается идти параллельным путем )))

 

[alexas1]

т.е. предлагается идти параллельным путем )))

ну, про параллельный путь давно понятно)
Не понятно, ток, зачем нода тому, кто вкурил икспейдж
Из-за сокетов "скаропки" и хайпа?
Ну, ещё, не топтаться в нотусёвом дизигнере... (Хотя, всё равно придёцца) а стоит оно того?

 

[garrick]

Вместо того, что бы старое в порядок привести еще одну новую свителку-перделку прикрутили... с новыми багами, а то старых нам мало было. Теперь со всей этой хуфигнёй точно взлетит.

 

[oshmianski]

Из-за сокетов "скаропки" и хайпа?
Ну, ещё, не топтаться в нотусёвом дизигнере... (Хотя, всё равно придёцца) а стоит оно того?

proton, domino-db, dql - на мой взгляд, полезные начинания.
gRPC(HTTP/2), node.js, react - скорее всего, за такими технологиями будущее.
и если HCL таки удастся успешно внедрить данные новшества, не похоронив nsf, то возможно придет больше пользователей и разработчиков, а с ними и развитие Lotus.

 

[VladSh]

... dql - на мой взгляд, полезные начинания.

Если для него нужно отстраивать вьюхи, то реальные продовые БД сразу же на похороны. Лучше уж эластик.

 

[lmike]

т.е. предлагается идти параллельным путем )))

я так один "проект" делаю, в хэпагах "сервлеты" загрузки/выгрузки/обработки бинарных файлов, остальное через DAS (в java), планирую покурить klehmann/domino-jna (правда для него нужна установка домины/нотусни)
ща лицуху на аспоз получу - переделаю базу генерации контрактов (полностью уйду с КОМы , а потом и из классики), POI/FOP/iText не хватает (верстка страдает) для конвертации в ПДФ (из docx)...

 

[oshmianski]

Для ui использую react + redux + router + material-ul, пишу в WebStorm, серверное rest api пока на хэпажных "сервлетах".
DAS не использую из-за непрозрачности и, если не ошибаюсь, у него проблемы с производительностью.
К domino-jna тоже присматриваюсь, но как-то уж через чур "монструозно". Пока стремно.

Вот жду рабочую версию стэка proton + domino-db + dql.

 

[lmike]

DAS не использую из-за непрозрачности и, если не ошибаюсь, у него проблемы с производительностью.

непрозрачность - в чем? Производительность - есть точно проблема с обновлением РТ (сделал через хэпагу), остальное не обращал внимание , по задаче не кажется критичным

 

[oshmianski]

1) DAS - это в основном HTTP GET - они кешируются, много параметром не передашь. Предпочитаю POST, сам конструирую структуру тела - нет кеша, параметры могут быть большими.
2) уже не могу найти, вроде где-то было сравнение для чтения представления: DAS vs ViewNavigator vs ReadViewEntries. ViewNavigator - победитель, его и использую. Тут могу врать, доказательств нету.
3) у меня "сервлеты" отдают подготовленный объекты бизнес-приложения, а не голые поля документов. Но это на мой вкус.
4) непрозрачность - это может я перегнул... имел в виду, лишнюю абстракцию (черный квадрат) над api по чтению данных из представлений и документов. предпочитаю иметь полный контроль. понятно, что domino-db - это новый аналог DAS, но по крайней мере быстрее (gRPC все таки).