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

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

alexas1

Lotus team
10.04.2014
726
145
#2
... просто я новичок и только знакомлюсь с данной продукцией)
Раз новичок, Вам всё равно - пишите на Xpages. Под Web писать ВЕСЬ интерфейс придётся.
Или, если надо шустро, раскручивайте боссов на http://xpagesdynamic.ru/ (не реклама, сам не пробовал, ходят слухи, что работает)
 

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 231
18
#4
просто дай доступ базе под веб и начни по кирпичику приводить к нормальному виду
про xPage - даже не думай, это мертвяк
 

alexas1

Lotus team
10.04.2014
726
145
#5
Ну для конвертации того что есть в xpage обнаружилось вот это:
Для просмотра контента необходимо: Войти или зарегистрироваться

цену не узнавал, но интересно
Это только простой дизайн.
По видео, код всех простых контролов выводят в CustomControls. Это жесть!
И конвертят они только @Formulas, LS оставляют "as is".
Т.е. без рук не обойтись никак.
 

savl

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

alexas1

Lotus team
10.04.2014
726
145
#7
На xpages делать "правильный" интерфейс в разы проще, чем в классике.
Непривычно, на первых порах, эт да.
Зато сделать можно всё, что сам придумал и что юзверь хочет.
Одна драгэнддропность, во всём, чего стоит.
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 586
272
#9
большая нагрузка на проц, не оптимизировано, слишком много лишних вычислений
в треде нет аргументов ;)
большая из-за чего и на какой проц (сервер/клиент). Что вычисляется лишнее сравнивая с ЛС?
и там и там - ВМ с байткодом. При этом - оптимизацией ЛС ВМ заниматься ИБМ явно не настроен

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

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

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

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

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 586
272
#10
Для просмотра контента необходимо: Войти или зарегистрироваться
там и про массивы есть и про стринги и про файлы (правда не в явной форме)
а после - интересно просканировать код на предмет использования массивов (в неэффективной форме) их итераторов
и стрингов
про файловые буферы - надо смотреть как NotesStream работает (возможно эффективней чем "старая" форма)
[DOUBLEPOST=1426192485,1426192327][/DOUBLEPOST]кста - еще про обращение к доку или к колонке - тоже забавно (если правда)
хотя тут мы поимеем возможное разрастание индекса (из-за саммари), но не факт - что саммари похачен, в большинстве приложений ;)
 
Симпатии: Понравилось savl

savl

Lotus team
28.10.2011
2 136
105
#11
вод там и про массивы есть и про стринги и про файлы (правда не в явной форме)
Читал, даже перечитывал, некоторые вещи очень полезны даже сейчас, другие уже не имеют смысла - наращивать мощность стало дешевле чем оптимизировать.
 

rinsk

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

lmike

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

erdi

Well-known member
20.08.2008
265
17
#14
вообще большая нагрузка на память, т.к. в основе JSF и все открытое у всех пользователей находится в памяти сервера

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

rinsk

Lotus team
12.11.2009
900
44
#15
насколько активно используются массивы и строки в циклах?
Совсем не используется.
А зачем вообще говоря в бакэнде при работе с базой нужны большие массивы строк\циклы? Я не встречал ничего такого для чего нужно больше массивы в памяти. Все остальное - во внешних БД.

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

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

alexas1

Lotus team
10.04.2014
726
145
#16
вообще большая нагрузка на память, т.к. в основе JSF и все открытое у всех пользователей находится в памяти сервера
А это разве проблема на современных серверах?;)
под xpages, это "боль и слезы".
Ну, ХЗ. Первая хепажная база была крутой риалтайм в вэбе, когда пять десятков юзверей зависят друг от друга - звери не жалуются, всё летает. Правда принцип, одна аппликуха - одна страница и минимум штатных контролов, дожо нет, жикери нет. Не потому, что заранее знал о какой то засаде, а просто не было знаний на старте. Щща бы сделал иначе.

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

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

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

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

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 586
272
#17
@erdi, @rinsk, коллеги согласие/несогласие - это некий процесс
что имеем:
- xPages кот. можно запустить как в варианте клиента (без домины) так и клиент-серверном
- нагрузка на память - все менее и менее актуален этот вопрос

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

savl

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

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 586
272
#19
@savl, вот есть приложение кот. должно работать как с сервером так и без, я не хочу писать какой-то велосипед
хэПагес мне это позволяют, а вынесение фронта на JS заставит велоспедить
 
Последнее редактирование модератором:

Darkhan

Lotus team
14.12.2012
98
2
#20
Есть подозрения, что при одинаковой нагрузке в противостоянии клиент/веб, хпагес будет колбасить не по-детски))