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

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

Молчанов

помогите как примерно готвую БД перевести под web я так понял надо создавать копии форм и вьюх только под веб а вот названия у них должны быть другие? или такиеже? просто я новичок и только знакомлюсь с данной продукцией)
 
... просто я новичок и только знакомлюсь с данной продукцией)
Раз новичок, Вам всё равно - пишите на Xpages. Под Web писать ВЕСЬ интерфейс придётся.
Или, если надо шустро, раскручивайте боссов на (не реклама, сам не пробовал, ходят слухи, что работает)
 
Ну для конвертации того что есть в xpage обнаружилось вот это:
цену не узнавал, но интересно
 
просто дай доступ базе под веб и начни по кирпичику приводить к нормальному виду
про xPage - даже не думай, это мертвяк
 
Ну для конвертации того что есть в xpage обнаружилось вот это:
цену не узнавал, но интересно
Это только простой дизайн.
По видео, код всех простых контролов выводят в CustomControls. Это жесть!
И конвертят они только @Formulas, LS оставляют "as is".
Т.е. без рук не обойтись никак.
 
Т.е. без рук не обойтись никак.
Это всегда так...
Учитывая, что на постсоветском пространстве очень много LS кода: миграция долгий процесс.
При этом не важно куда мигрируешь.
ToxaRat
Почему ты считаешь что xPage скорее труп? Из-за dojo?
 
На xpages делать "правильный" интерфейс в разы проще, чем в классике.
Непривычно, на первых порах, эт да.
Зато сделать можно всё, что сам придумал и что юзверь хочет.
Одна драгэнддропность, во всём, чего стоит.
 
большая нагрузка на проц, не оптимизировано, слишком много лишних вычислений
в треде нет аргументов ;)
большая из-за чего и на какой проц (сервер/клиент). Что вычисляется лишнее сравнивая с ЛС?
и там и там - ВМ с байткодом. При этом - оптимизацией ЛС ВМ заниматься ИБМ явно не настроен

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

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

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

А вот нарекания на скорость и гибкость ЛС вполне себе обоснованы (работы со стрингами/массивами - пп, хмл парсерры тудаже) ограничения по памяти/мультипоточности
ОО в ЛС тоже полная опа, просвета в кот. не будет уже никогда (ИБМ закопал ЛС)
 
там и про массивы есть и про стринги и про файлы (правда не в явной форме)
а после - интересно просканировать код на предмет использования массивов (в неэффективной форме) их итераторов
и стрингов
про файловые буферы - надо смотреть как NotesStream работает (возможно эффективней чем "старая" форма)
[DOUBLEPOST=1426192485,1426192327][/DOUBLEPOST]кста - еще про обращение к доку или к колонке - тоже забавно (если правда)
хотя тут мы поимеем возможное разрастание индекса (из-за саммари), но не факт - что саммари похачен, в большинстве приложений ;)
 
  • Нравится
Реакции: savl
вод там и про массивы есть и про стринги и про файлы (правда не в явной форме)
Читал, даже перечитывал, некоторые вещи очень полезны даже сейчас, другие уже не имеют смысла - наращивать мощность стало дешевле чем оптимизировать.
 
Смотря на 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 заставит велоспедить
 
Последнее редактирование модератором:
Есть подозрения, что при одинаковой нагрузке в противостоянии клиент/веб, хпагес будет колбасить не по-детски))
 
Мы в соцсетях:

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