Как сделать "computed subform" на xpages?

[rinsk]

- лучше, всё же, грузить заранее подготовленные СС, чем заморачиваться кусочками.

-эт имхо от задачи уже зависит... Вот гляжу иньекции гемор еще тот и склоняюсь на рисовании во фронтэнде полей и взаимодействие с базрй через RPC

 

[Hogmuzzle]

- "это идеально подходит", на сложной страничке может привести к её медленному умиранию (в смысле быстродействия), а вот display:none подойдёт, но, элемент будет на странице(
- ни что не мешает вместе с JSF использовать simpleHTML - как хочу, так и изменяю DOM.
- и что из этого вытекает? getComponent не будет работать?
И ващще, обращаться к серверу с каждым телодвижением - не comme il faut, можешь сделать на CSJS - делай.
Задача сводится к следующим моментам:
1 во время работы загрузка CustomControls в нужные места по условиям (один из вариантов отмечен выше - работает на ура)
2 если необходимо сохранить динамически изменённый дизайн странички, вместе с сохранением дока, сохранить последние условия, по которым грузились СС и новые айтемы, если они появились.
3 при последующем открытии этой странички - сразу подгрузить нужные контролы по сохранённым в доке условиям.
- лучше, всё же, грузить заранее подготовленные СС, чем заморачиваться кусочками.

Все очень ситуативно. Разработка это всегда компромисс. Не будет работать не только getComponent но и значение с Post не попадут на сервер например. Хранить что то в документе кроме данных это на мой взгляд не правильно и противоречит MVC подходу. Потом после вас народ будет волосы на ... рвать. Если есть технология JSF то и писать нужно согласно ее парадигме. Вообще можно на Xpages front-end на AngularJs забубенить только зачем?

 

[NickProstoNick]

Все очень ситуативно. Разработка это всегда компромисс. Не будет работать не только getComponent но и значение с Post не попадут на сервер например. Хранить что то в документе кроме данных это на мой взгляд не правильно и противоречит MVC подходу. Потом после вас народ будет волосы на ... рвать. Если есть технология JSF то и писать нужно согласно ее парадигме. Вообще можно на Xpages front-end на AngularJs забубенить только зачем?

При динамическом добавлении кастом котролов работает и getComponent и все методы доступа к данным, есть контекст документа. (по крайней мере я не столкнулся с проблемой сохранения документов), можно получить и datasource из созданного кастом контрола

 

[alexas1]

При динамическом добавлении кастом котролов работает и getComponent и все методы доступа к данным, есть контекст документа. (по крайней мере я не столкнулся с проблемой сохранения документов), можно получить и datasource из созданного кастом контрола

- Йесс!
Воркает всё.
Из западло только коррекция жаваполиси и лень

 

[NickProstoNick]

- Йесс!
Воркает всё.
Из западло только коррекция жаваполиси и лень

Не знаю. Этих проблем тоже нет. Никаких дополнительных настроек политик не делал.

 

[alxndr]

Мне то же интересно, как в бакэнде поменять тек. дерево. - только стоит задача не подформу динамически "встраивать" , а набор элементов управления (до сотни полей+лейоуты ), которые компонуются из справочника в зависимости от тек. состояния док-та. Ест-сно они при post должны упасть в базу...

Если задача стоит динамически встроить до сотни полей на форму xpages, то вполне подойдет repeat control, где в качестве источника данных подается js массив (например из справочника), а перед сохранением массив "распихивается" по полям, либо складывается в одно multivalue поле. По-моему так... Про лейоуты не понял.

 

[rinsk]

вполне подойдет repeat control

Если оно не встраивается в дерево, то там много способов доставить на фронт-энд сами поля со справочника вместе со значением из бакэнд . В классик вебе такую доставку можно делать и wqo агенте и раскидывать по форме через аякс запрос - при штатной серелизации все нормально падает в бакэнд.

а перед сохранением массив "распихивается" по полям

Дак "полей" то нет на форме - или реч о бакэнд документе?

Про лейоуты не понял.

Ну банальная группировка полей по функционалу - что бы не портянкой все шло )

 

[alexas1]

Дак "полей" то нет на форме - или реч о бакэнд документе?

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

 

[alxndr]

Если оно не встраивается в дерево, то там много способов доставить на фронт-энд сами поля со справочника вместе со значением из бакэнд . В классик вебе такую доставку можно делать и wqo агенте и раскидывать по форме через аякс запрос - при штатной серелизации все нормально падает в бакэнд.

"оно", т.е. все элементы созданные через repeat "встраивается" в дерево JSF, т.е. каждому элементу UI в клиенте (checkbox, input, button ...) соответствует серверный компонент JSF, соответственно просабмитив веб-форму мы получим доступ ко всем данным, введенным пользователем (посредством ssjs)

Дак "полей" то нет на форме - или реч о бакэнд документе?

Стоит разделять модель данных от представления (UI) - "полей" в классическом понимании лотуса может и не быть- как я писал ранее все значения могут храниться в одном поле (multivalue), а могут быть порождены и отдельные поля - тут уж как пожелаете, ну и в любом случае этот процесс (разбор массива и запихивание значений в поле/поля) придется слегка дописать ручками

Ну банальная группировка полей по функционалу - что бы не портянкой все шло )

Некоторое усложнение модели "справочника" (хранение полей по группам) и тег <tr>

Есть, кстати, еще один интересный подход - xp:customConverter, тут тоже можно "раскрутить" одно поле в целую страницу html, а потом опять свернуть в поле... Но этот путь я проходил только наполовину.

 

[lmike]

дорогие коллеги,
дабы не "засирать" топик абстракциями - предлагаю идеи оформлять кусками кода или бд
ибо сказано много, а человек, кот. захочет найти по теме "решение" - обламается (читая портянки)