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

 

... просто я новичок и только знакомлюсь с данной продукцией)

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

 

Ну для конвертации того что есть в xpage обнаружилось вот это: https://sites.google.com/site/effichangecom/home/xpager
цену не узнавал, но интересно

 

просто дай доступ базе под веб и начни по кирпичику приводить к нормальному виду
про xPage - даже не думай, это мертвяк

 

Ну для конвертации того что есть в xpage обнаружилось вот это: https://sites.google.com/site/effichangecom/home/xpager
цену не узнавал, но интересно

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

 

Т.е. без рук не обойтись никак.

Это всегда так...
Учитывая, что на постсоветском пространстве очень много LS кода: миграция долгий процесс.
При этом не важно куда мигрируешь.
ToxaRat
Почему ты считаешь что xPage скорее труп? Из-за dojo?

 

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

 

ToxaRat
Почему ты считаешь что xPage скорее труп? Из-за dojo?

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

 

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

в треде нет аргументов
большая из-за чего и на какой проц (сервер/клиент). Что вычисляется лишнее сравнивая с ЛС?
и там и там - ВМ с байткодом. При этом - оптимизацией ЛС ВМ заниматься ИБМ явно не настроен

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

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

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

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

 

вод там и про массивы есть и про стринги и про файлы (правда не в явной форме)
а после - интересно просканировать код на предмет использования массивов (в неэффективной форме) их итераторов
и стрингов
про файловые буферы - надо смотреть как NotesStream работает (возможно эффективней чем "старая" форма)
[DOUBLEPOST=1426192485,1426192327][/DOUBLEPOST]кста - еще про обращение к доку или к колонке - тоже забавно (если правда)
хотя тут мы поимеем возможное разрастание индекса (из-за саммари), но не факт - что саммари похачен, в большинстве приложений

 

вод там и про массивы есть и про стринги и про файлы (правда не в явной форме)

Читал, даже перечитывал, некоторые вещи очень полезны даже сейчас, другие уже не имеют смысла - наращивать мощность стало дешевле чем оптимизировать.

 

Смотря на openntf.org действительно хочется подумать что " это мертвяк". Такого бестолкового применения xpages надо еще придумать, а за выставление на общее обозрение - распять.

Что вычисляется лишнее сравнивая с ЛС?

Вычисляется JSF дерево.

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

На счет скорости -
Ну протестил я скорость обработки простой задачи - а ля активности пользователя на агенте и типа xAgent - сбор окружения пользователя, поиск в базе, апдейты и тп. через $.ajax - как было 5-10 мс так оно и осталось. Единственный цимус - эт всякие *scope которых нет по определению в agent\form (AKA CGI) и + внешние java библы, коих море.
И таки да - entry.ColumnValues() гораздо шустрее.
Все остальное - как во всех языках - нужно подходить критически и внимательно.

 

Все остальное - как во всех языках - нужно подходить критически и внимательно.

именно, но если в др. языках совершенствуют движки, то для ЛС этого не будет
32бит как были так и будут (к кот. добавлены еще и ограничения по индексам в массивах). При этом - конструкции кот. надо мантырить для ЛС (чтобы не воткнутся в особенности) будут не совсем очевидны, часто - громоздки

Ну протестил я скорость обработки простой задачи - а ля активности пользователя на агенте и типа xAgent - сбор окружения пользователя, поиск в базе, апдейты и тп. через $.ajax - как было 5-10 мс так оно и осталось.

насколько активно используются массивы и строки в циклах?
[DOUBLEPOST=1426230951,1426230655][/DOUBLEPOST]

наращивать мощность стало дешевле чем оптимизировать.

апликейшены домины долгоживущие, как пр-ло, и наращивание мощности происходит быстрее, чем их устаревание - это совсем не означает что можно забить на нек. оптимизации
@all моим основным посылом было опровергнуть заявления:

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

и

про xPage - даже не думай, это мертвяк

 

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

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

 

насколько активно используются массивы и строки в циклах?

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

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

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

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

 

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

А это разве проблема на современных серверах?

под xpages, это "боль и слезы".

Ну, ХЗ. Первая хепажная база была крутой риалтайм в вэбе, когда пять десятков юзверей зависят друг от друга - звери не жалуются, всё летает. Правда принцип, одна аппликуха - одна страница и минимум штатных контролов, дожо нет, жикери нет. Не потому, что заранее знал о какой то засаде, а просто не было знаний на старте. Щща бы сделал иначе.

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

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

всяко действо должно пройти через сервер.

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

поддержка WebSocket на уроне сервера

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

 

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

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

 

-JS - ну и как это программить деплоить - если клиентское приложение д.б., с репликацей?

Может чего-то не допонимаю, но: Если есть клиент, то ничем не отличается от текущей не xPage, если клиента нет, то только браузер(значит все остальное на сервере)

 

@savl, вот есть приложение кот. должно работать как с сервером так и без, я не хочу писать какой-то велосипед
хэПагес мне это позволяют, а вынесение фронта на JS заставит велоспедить

 

Есть подозрения, что при одинаковой нагрузке в противостоянии клиент/веб, хпагес будет колбасить не по-детски))