mt & log web-читалка

А зачем это в таком, казалось бы, незамысловатом приложении?

как минимум скорость, да доп. фичи могут пригодиться

 

Я вот всё думаю - есть ли какое-то преимущество в подобной технологии перед XPages? Во-первых хак через задний ход, который может отвалится/закрыться с каким-нибудь фикс-паком или новой версией. Во-вторых КМК неудобно мапить данные через JSON на поля, особенно на таблицы (view), ну, т.е. менее удобно чем через Document и View в XPages.

 

Сложно сказать. Весомые преимущества тоже могут меняться со временем.

Сейчас для меня преимущества:
1) front-end - react, redux, node.js, webpack - знания, повышающие ценность на рынке труда
2) IDE для клиентской части - WebStrom - не сравнить с текущим Domino Designer, отвязка он Windows
3) нормальная VCS для front-end
4) богатый выбор клиентских компонентов UI

 

Сложно сказать. Весомые преимущества тоже могут меняться со временем.

Сейчас для меня преимущества:
1) front-end - react, redux, node.js, webpack - знания, повышающие ценность на рынке труда
2) IDE для клиентской части - WebStrom - не сравнить с текущим Domino Designer, отвязка он Windows
3) нормальная VCS для front-end
4) богатый выбор клиентских компонентов UI

Всё это здорово и интересно, но возникает вопрос "а на паркуа" во всём этом зоопарке Domino? По-моему Domino тут уже лишнее.

P.S. всегда было интересно как в подобных случаях (тот же React) делаются таблицы с большим набором данных. Есть какие-то готовые компоненты с постраничным пролистваением как ViewPanel в Xpages или набор данных надо самостоятельно вручную резать на страницы?

 

react - альтернатива xPages. Кто что лучше умеет, тот то и готовит, как мне кажется.

Разделять web приложение на back-end и front-end правильно, на мой взгляд. Можно относительно легко менять и первое и второе.

react - это маленькая библиотечка только лишь по манипулированию DOM. В экосистеме react есть много готовых компонентов, а-ля ViewPanel, которые умеют в том числе сами резать на страницы большие наборы данных (клиентская пагинация), есть готовая виртуализация. Но чудес не бывает - везде есть сложности и нужет напильник, с чем то приходится мириться. Например, мне пока не удалось по-человечески сделать динамическую виртуальную серверную пагинацию - lazy списки.

 

Например, мне пока не удалось по-человечески сделать динамическую виртуальную серверную пагинацию - lazy списки.

Именно про это и спрашивал. Технически не сложно в Domino или JDBC (не знаю как с JPA/Hibernate), но ручной возни/писанины много.
Например показать из вьюхи З0 документов начиная с 31-го (вторая страница при разбивке по 30 записей)

Загрузка...

www

.lotus-10.com/leads.nsf/DDC087A8ACE170F8852562F30070226400000196?OpenView&Start=31&Count=30

URL commands for opening servers, databases, and views

В JDBC тоже есть возможность постраничной навигации по Resultset.

 

Да, на серверной стороне это не сложно и это реализовано в серверной части mt&log. Все упирается в клиентскую часть. Пробовал много разных компонентов. Но нужного результата не получил. В большей части загвоздка в динамической высоте строк (например при изменении ширины колонки). В основном react-виртуализация построена на фиксированной высоте строк. Но это не удобно, не естественно.

 

Попробовал сделать небольшое демо на Реакте. В Ноде всё хорошо, но при попытке вживить это в Домино начинается какая-то чехарда с путями к скриптам, картинкам и пр. Т.е. npm run build прописывает все пути начиная с "/", например, "/script.js". Это нормально если всё оно располагается где-то в "корне" сервера, например "www.domino.com/script.js", но нам же нужно указать путь до файла базы данных + сам файл, т.е. "www.domino.com/path/file.nsf/script.js". Можно ли это сразу сорбрать должным образом в NPM, что бы затем не править всё отдельно в Domino Designer? Мне кажется достаточно везде убрать начальный слеш и должно заработать. Может ключ какой-то есть при сборке?

 

Как собираете?

 

создают проект
create-react-app
правлю его, потом
npm run build
то, что образуется в папке build импортирую в WebContent nsf базы.
Пишу в адресной строке путь до index.html и запускаю его. Вот пример заголовка index.html

<!doctype html>
<html lang="en">

<head>
    <meta charset="utf-8" />
    <link rel="icon" href="/favicon.ico" />
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <meta name="theme-color" content="#000000" />
    <meta name="description" content="Web site created using create-react-app" />
    <link rel="apple-touch-icon" href="/logo192.png" />
    <link rel="manifest" href="/manifest.json" />
    <title>React App</title>
    <link href="/static/css/main.d1b05096.chunk.css" rel="stylesheet">
</head>

Пути к ресурсам (js, css и пр.) начинаются со слеша, если его убрать, то всё хорошо.

 

Да, нужно убрать лидирующие слеши.

1) Использую webpack для сборки.
2) Использую плагин к webpack - html-webpack-plugin и разные webpack-конфиги - для dev и prod.
3) Не использую css. Вместо него jss.

У меня есть тестовый реакт проектик с fakenames2018.nsf на bitbucket.org. Если интересно, могу открыть.

 

Вот это и проблема. Убирать уже в готовом, собраном проекте то ещё удовольствие, как бы сразу собрать правильно, без слешей.

1. npm вроде тоже Webpack вызывает
2. ??? для меня это пока тёмный лес - ничего не понял
3. Ну я сам тоже никаких CSS не подключал, только material-ui. Это оно само нагородило такое.

Конечно интересно.

 

fakenames-react

 

fakenames-react

Спасибо.
Клонировал себе, посмотрю как будет время.

 

прописывает все пути начиная с "/", например, "/script.js".

Читаю. К чему такие сложности с реактами и jss? Может модно так сейчас...
Те же пути в $$HTMLHead переменной сразу задал хочешь со слешом - хочешь без.
substitution := @If(Server_Name="test.online";
"/";
"/test/");
editorial :="<link href='"+substitution+"css/main-editorial.css' rel='stylesheet'>";

Обсуждалка Маскирование .nsf в URL и HTML directory: domino\html

И base обязательно "<base href=\"http://" + Server_Name + "/hop/" + "\">"; С него уже хоть страница, хоть форма, хоть агент легко адресуется просто по имени.

Может я канвы не понял?

 

Тут речь о node.js проекте. Разрабатываться и тестироваться можетв одной среде (один base), а деплоиться и исполняться в другой (другой base).

 

и ссылку на перевод про сервлет с китайского здесь оставлю меньше кликов нужно будет (похожее)

В связи с переездом всего и вся на сайт HCL китайская ссылка пропала (вела на сайт IBM).

 

В связи с переездом всего и вся на сайт HCL китайская ссылка пропала (вела на сайт IBM).

ну я не смогу это исправить