Азы Для Переработки Готовой Бд Под Web

  • Автор темы Молчанов
  • Дата начала
М

Молчанов

помогите как примерно готвую БД перевести под web я так понял надо создавать копии форм и вьюх только под веб а вот названия у них должны быть другие? или такиеже? просто я новичок и только знакомлюсь с данной продукцией)
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
45
... просто я новичок и только знакомлюсь с данной продукцией)
Раз новичок, Вам всё равно - пишите на Xpages. Под Web писать ВЕСЬ интерфейс придётся.
Или, если надо шустро, раскручивайте боссов на (не реклама, сам не пробовал, ходят слухи, что работает)
 

savl

Lotus Team
28.10.2011
2 624
314
BIT
541
Ну для конвертации того что есть в xpage обнаружилось вот это:
цену не узнавал, но интересно
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
просто дай доступ базе под веб и начни по кирпичику приводить к нормальному виду
про xPage - даже не думай, это мертвяк
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
45
Ну для конвертации того что есть в xpage обнаружилось вот это:
цену не узнавал, но интересно
Это только простой дизайн.
По видео, код всех простых контролов выводят в CustomControls. Это жесть!
И конвертят они только @Formulas, LS оставляют "as is".
Т.е. без рук не обойтись никак.
 

savl

Lotus Team
28.10.2011
2 624
314
BIT
541
Т.е. без рук не обойтись никак.
Это всегда так...
Учитывая, что на постсоветском пространстве очень много LS кода: миграция долгий процесс.
При этом не важно куда мигрируешь.
ToxaRat
Почему ты считаешь что xPage скорее труп? Из-за dojo?
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
45
На xpages делать "правильный" интерфейс в разы проще, чем в классике.
Непривычно, на первых порах, эт да.
Зато сделать можно всё, что сам придумал и что юзверь хочет.
Одна драгэнддропность, во всём, чего стоит.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
471
большая нагрузка на проц, не оптимизировано, слишком много лишних вычислений
в треде нет аргументов ;)
большая из-за чего и на какой проц (сервер/клиент). Что вычисляется лишнее сравнивая с ЛС?
и там и там - ВМ с байткодом. При этом - оптимизацией ЛС ВМ заниматься ИБМ явно не настроен

на сервере - так живет весь "большой" мир - под джавой крутится и разрабатывается большинство приложений
JavaScript аки не вызывает нареканий по производительности и во весь рост используется в SSJS.

Легко подключаются клиентские либы типа ExtJS/JQuery если dojo чем-то не устраивает.

Производительность на клиенте определяется рендерером (что не является экзотикой - обычный вебдвижок) и запуском минисервера. Вот тут есть некая просадка, но пардонте - на современных компах легко запускаются локальные сервера (коих винда несет на своем борту туевухучу, достаточно поглядеть в сервисы) и ЦП это спокойно переваривает
Недалече - .НЕТ порядочно тащит с собой хлама и никто этим не возмущен ;)

А вот нарекания на скорость и гибкость ЛС вполне себе обоснованы (работы со стрингами/массивами - пп, хмл парсерры тудаже) ограничения по памяти/мультипоточности
ОО в ЛС тоже полная опа, просвета в кот. не будет уже никогда (ИБМ закопал ЛС)
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
471
там и про массивы есть и про стринги и про файлы (правда не в явной форме)
а после - интересно просканировать код на предмет использования массивов (в неэффективной форме) их итераторов
и стрингов
про файловые буферы - надо смотреть как NotesStream работает (возможно эффективней чем "старая" форма)
[DOUBLEPOST=1426192485,1426192327][/DOUBLEPOST]кста - еще про обращение к доку или к колонке - тоже забавно (если правда)
хотя тут мы поимеем возможное разрастание индекса (из-за саммари), но не факт - что саммари похачен, в большинстве приложений ;)
 
  • Нравится
Реакции: savl

savl

Lotus Team
28.10.2011
2 624
314
BIT
541
вод там и про массивы есть и про стринги и про файлы (правда не в явной форме)
Читал, даже перечитывал, некоторые вещи очень полезны даже сейчас, другие уже не имеют смысла - наращивать мощность стало дешевле чем оптимизировать.
 

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
45
Смотря на openntf.org действительно хочется подумать что " это мертвяк". Такого бестолкового применения xpages надо еще придумать, а за выставление на общее обозрение - распять.
Что вычисляется лишнее сравнивая с ЛС?
Вычисляется JSF дерево.
А вот нарекания на скорость и гибкость ЛС вполне себе обоснованы (работы со стрингами/массивами - пп, хмл парсерры тудаже) ограничения по памяти/мультипоточности
ОО в ЛС тоже полная опа, просвета в кот. не будет уже никогда (ИБМ закопал ЛС)
На счет скорости -
Ну протестил я скорость обработки простой задачи - а ля активности пользователя на агенте и типа xAgent - сбор окружения пользователя, поиск в базе, апдейты и тп. через $.ajax - как было 5-10 мс так оно и осталось. Единственный цимус - эт всякие *scope которых нет по определению в agent\form (AKA CGI) и + внешние java библы, коих море.
И таки да - entry.ColumnValues() гораздо шустрее.
Все остальное - как во всех языках - нужно подходить критически и внимательно.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
471
Все остальное - как во всех языках - нужно подходить критически и внимательно.
именно, но если в др. языках совершенствуют движки, то для ЛС этого не будет
32бит как были так и будут (к кот. добавлены еще и ограничения по индексам в массивах). При этом - конструкции кот. надо мантырить для ЛС (чтобы не воткнутся в особенности) будут не совсем очевидны, часто - громоздки
Ну протестил я скорость обработки простой задачи - а ля активности пользователя на агенте и типа xAgent - сбор окружения пользователя, поиск в базе, апдейты и тп. через $.ajax - как было 5-10 мс так оно и осталось.
насколько активно используются массивы и строки в циклах?
[DOUBLEPOST=1426230951,1426230655][/DOUBLEPOST]
наращивать мощность стало дешевле чем оптимизировать.
апликейшены домины долгоживущие, как пр-ло, и наращивание мощности происходит быстрее, чем их устаревание - это совсем не означает что можно забить на нек. оптимизации
@all моим основным посылом было опровергнуть заявления:
большая нагрузка на проц, не оптимизировано, слишком много лишних вычислений
и
про xPage - даже не думай, это мертвяк
 

erdi

Green Team
20.08.2008
264
17
BIT
0
вообще большая нагрузка на память, т.к. в основе JSF и все открытое у всех пользователей находится в памяти сервера

может кто-то и научился это все "готовить", но для меня, хоть и есть у меня несколько баз под xpages, это "боль и слезы". Больше 3 дней не хватает терпения под ними работать :) И если встанет острый вопрос о необходимости полного стека на web, то я лучше разделю на бэк и фронт. Бэк либо свой зоопарк OSGI, либо DOTS, а фронт любой JS фреймворк под nginx
тем более что xpagex на OSGI и работает....так зачем лишняя прослойка :)
 

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
45
насколько активно используются массивы и строки в циклах?
Совсем не используется.
А зачем вообще говоря в бакэнде при работе с базой нужны большие массивы строк\циклы? Я не встречал ничего такого для чего нужно больше массивы в памяти. Все остальное - во внешних БД.

вообще большая нагрузка на память, т.к. в основе JSF и все открытое у всех пользователей находится в памяти сервера
Вот именно - и в 90% случаев такой оверхед нафиг не нужен. Само по себе front end\back end sync state - вещь конечно полезная, но я не согласен с навязываемой парадигмой xpage, что всяко действо должно пройти через сервер.

PS - Вот нативная поддержка WebSocket на уроне сервера\дизайнера была бы полезнее..
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
45
вообще большая нагрузка на память, т.к. в основе JSF и все открытое у всех пользователей находится в памяти сервера
А это разве проблема на современных серверах?;)
под xpages, это "боль и слезы".
Ну, ХЗ. Первая хепажная база была крутой риалтайм в вэбе, когда пять десятков юзверей зависят друг от друга - звери не жалуются, всё летает. Правда принцип, одна аппликуха - одна страница и минимум штатных контролов, дожо нет, жикери нет. Не потому, что заранее знал о какой то засаде, а просто не было знаний на старте. Щща бы сделал иначе.

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

Личное ИМХО: разработка на xpages - быстро, удобно, функционально. (скорость оставил за бортом - с гемором не сталкивался, наверное не было супер задач)

всяко действо должно пройти через сервер.
Это почему? И почему навязываемая парадигма? Не хочешь - не используй, где можешь обойтись.

поддержка WebSocket на уроне сервера
Встроенной нет, эт да. А вот довесок есть, проблем в использовании нет.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
471
@erdi, @rinsk, коллеги согласие/несогласие - это некий процесс
что имеем:
- xPages кот. можно запустить как в варианте клиента (без домины) так и клиент-серверном
- нагрузка на память - все менее и менее актуален этот вопрос

а вот с велосипедами уже все сложнее:
- DOTS на клиенте можно (теоретически) но вряд ли поддерживаемое
-JS - ну и как это программить деплоить - если клиентское приложение д.б., с репликацей?
[DOUBLEPOST=1426237049,1426236963][/DOUBLEPOST]в "старом" стиле приложение было единообразно при запуске локально или с сервера (в толстом клиенте)
на хПгах - все будет подобно
 
Последнее редактирование модератором:

savl

Lotus Team
28.10.2011
2 624
314
BIT
541
-JS - ну и как это программить деплоить - если клиентское приложение д.б., с репликацей?
Может чего-то не допонимаю, но: Если есть клиент, то ничем не отличается от текущей не xPage, если клиента нет, то только браузер(значит все остальное на сервере)
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
471
@savl, вот есть приложение кот. должно работать как с сервером так и без, я не хочу писать какой-то велосипед
хэПагес мне это позволяют, а вынесение фронта на JS заставит велоспедить
 
Последнее редактирование модератором:

Darkhan

Green Team
14.12.2012
99
2
BIT
0
Есть подозрения, что при одинаковой нагрузке в противостоянии клиент/веб, хпагес будет колбасить не по-детски))
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!