Вопрос Про Rest Service

Люди добрые подскажите как добавить несколько значений с вьюхи в компонент Rest Service что бы они складывались, во вложении описано куда. Пробовал vEvent+vPeople (это поля с вьюхи) не работает, я так понял что это можно сделать тольско с помощью java script, но я не знаю как обратиться через него к этим полям

0

Есть документ организация (поле fORG), есть документ сотрудник (ref к организации) поля: pFIO, pORG, есть документ событие (ref к сотруднику) поля :eStart, eEnd, eFIO,eORG. Вопрос в том, как мне сделать так что бы при изменении имени сотрудника во всех документах "события" тоже были новые значения. Если я сохраняю в документе не имя сотрудника а unid, то как мне потом во вьюхе отображать Имя пользователя а не unid?? Событий будет много. Ну и с организацией то же самое, просто не понимаю как связать это все ) ???

0

Сообщение от JohnLemon Есть документ организация (поле fORG), есть документ сотрудник (ref к организации) поля: pFIO, pORG, есть документ событие (ref к сотруднику) поля :eStart, eEnd, eFIO,eORG. Вопрос в том, как мне сделать так что бы при изменении имени сотрудника во всех документах "события" тоже были новые значения. Если я сохраняю в документе не имя сотрудника а unid, то как мне потом во вьюхе отображать Имя пользователя а не unid?? Событий будет много. Ну и с организацией то же самое, просто не понимаю как связать это все ) ???

Тебе писали... учи классику... базовые методы и функции.
Во view толстого клиента - никак. Там нужны статические значения.
В web - можно. В SSJS добавлены некоторые функции @formula. Жаль этой нет @GetDocField( documentUNID ; fieldName )
WEB вообще достаточно гибкий. Просто немного подумать надо :D В свойстве колонки вида можно делать практически что угодно. Дальше берешь документ по юниду и вперед



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

0

Сообщение от NickProstoNick Во view толстого клиента - никак. Там нужны статические значения.

А как решаются подобные задачи в толстом клиенте, как вообще связываются данные??
Можешь подсказать еще что такое rowData )? И что за значения должны быть в pOrg имя организации или ID fOrg ???

0

А как решаются подобные задачи в толстом клиенте, как вообще связываются данные??

Такие вещи, как названия организаций и ФИО сотрудников, заносятся во все связанные документы (для отображения в видах), при изменении данных в справочнике они меняются фоновым агентом во всех документах. Это классический вариант.
Другое дело, что я с трудом представляю себе задачу, при которой данные справочников меняются постоянно...

0

Сообщение от Мыш они меняются фоновым агентом во всех документах

Есть ссылка на пример ? Просто не догоняю чутка как искать документы где изменилось фио или организация, а потом еще и менять это в других документах, причем же ФИО у разных людей может быть одинаковое (

Другое дело, что я с трудом представляю себе задачу, при которой данные справочников меняются постоянно...

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

0

Есть ссылка на пример ? Просто не догоняю чутка как искать документы где изменилось фио или организация, а потом еще и менять это в других документах, причем же ФИО у разных людей может быть одинаковое

Навскидку. В каждом рабочем документе сохраняем ФИО человека и его уникальный ID (ID генерится при создании человека а справочнике). Агент проверяет дату модификации документов справочника, при ее изменении отбирает все рабочие документы, в которых указан ID человека и заменяет ФИО. Ну ессно, желательно проверять, что именно изменилось (и изменилось ли реально - ведь документ можно просто пересохранить, не меняя значения полей) в документе справочника, дабы не обновлять рабочие документы попусту.

0

Ну ессно, желательно проверять, что именно изменилось

Как проверить то ? Создавать еще одно поле скрытое или можно проще как то ?

0

Сообщение от JohnLemon Как проверить то ? Создавать еще одно поле скрытое или можно проще как то ?

чтоб строить проверку - надо знать как будет изменяться документ.
Но в любом случае - куда-то сохраняешь старые значения, а потом перед/после сохранением проверяют старые и новые значения.

0

Сообщение от NickProstoNick Тебе писали... учи классику... базовые методы и функции. Во view толстого клиента - никак. Там нужны статические значения. В web - можно. В SSJS добавлены некоторые функции @formula. Жаль этой нет @GetDocField( documentUNID ; fieldName ) WEB вообще достаточно гибкий. Просто немного подумать надо ;) В свойстве колонки вида можно делать практически что угодно. Дальше берешь документ по юниду и вперед Посмотреть вложение 6190 Посмотреть вложение 6191 Если нужна категоризация по организации - то нужны статические данные подразделений в документах. В общем все зависит от задачи...

Тут не подскажешь :D , что за значения должны быть в pOrg имя организации или ID fOrg ???

0

рекомендую начать с самого начала и с обычного клиента.
Практика практикой, но теорию почитать надо.
Рекомендую посмотреть на дизайн существующих баз.
И пробовать с самого простого. Если пытаешься применить "нормальные формы" к посторению БД в лотусе - забудь. По крайней мере для толстого клиента.
На WEB можно попробовать сделать все по правильному.
- Для иерархии подразделений (если есть документы подразделений) и сотрудников - достаточно в каждом подразделении содержать только название подразделения, а в карточке сотрудника ничего не надо. Ну и конечно же иерархия по респонсам.
- Для иерархии ТОЛЬКО сотрудников - в карточке сотрудника должен быть полный путь подразделений через \
- Для иерархии твоих заданий, которые привязаны к персонам - надо хранить и ФИО сотрулника и его полное подразделение. Т.к. построить вид только по сотруднику и его заданию не получится, т.к. сотрудник сам по себе респонс., а вид для иерархии должен начинаться с документа, а не респонса.

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

0

Сообщение от NickProstoNick Для иерархии ТОЛЬКО сотрудников - в карточке сотрудника должен быть полный путь подразделений через \

Что значит полный путь через \??

0

Джонни, заканчивай с хпагесами, СМС-ками и т.д. Учи классику. Тебе, уже, не один человек об этом сказал.
"\"-это "разделитель" при отображении в категоризированной колонке.
Пойми уже, что Доминоха, это не Джумала и остальная фиготень, где можно ничего не зная делать сайты. Доминоха это достаточно серьёзная система, требующая от человека знания её архитектуры + крайне жалательно знания всех "глюков" (особенностей и т.д.). Не зная основ и глюков человек превращается в говнокодера, коих просто тьма. Вон, одного говнокодера уволили две недели назад. до сих пор разгребаю его говно. Провалы в элементарных знаниях, приводит к тому, что задваиваются (да что там задваиваются, за 3700-ряются) документы, которые обязаны быть уникальными (и это, за 2-ва года, человек, так и не запомнил как работают вьюхи... при этом оригинальная база 800мб против 80мб переделанной. Документы 151т. (и это, оптимизированно на ходу, когда базу получил в руки, там под 400т. было. 151т. это максимум до которого можно урезать, без потери связей с другими базами) против 30т.). При этом всём, в "оригинале" допущены ошибки в "основах", которые блокируют дальнейшее развитие базы (а сейчас, для неё, только "старт"), при этом, новая версия с 30т. документами значительно меньше, быстрее, правильней и, самое главное, служит для дальнейшего развития системы. За две недели моей работы, в первые три дня, я закрыл 99% проблем, которые не смог закрыть говнокодер за 3-ри месяца. В данный момент осталась только одна проблема (из известных) это обновление данных из SQL (именно обновление, а не первоначальный импорт или дополнение). За сегодня данную проблему, думаю, доделаю. Итого, за две недели, я почти сделал систему, которую, более чем за три месяца не смог сделать говнокодер. Как тебе разница по времени/функционалу/проблемам?