• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Отбор во вью по полям ответов

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

LuMee

Можно ли составить формулу отбора во вью таким образом, чтобы отбирались документы-ответы, удовлетворяющие определенным условиям, а также все родительские документы для выбранных ответов?
Или, как вариант, другой вопрос: можно ли сделать так, чтобы для ответов во вью отображать значения каких-то полей родителей? Здесь, понимаю, задача еще труднее... Лично мне ничего на ум, кроме @GetDocField(@ParentDocumentId; "SomeField"), не приходит, однако в столбце вью такое точно не заработает.
 
O

Ogion7

можно ли сделать так, чтобы для ответов во вью отображать значения каких-то полей родителей
Сделай в форме ответа поле, в которое запиши информацию из родителя, при создании ответа
 
L

LuMee

Сделай в форме ответа поле, в которое запиши информацию из родителя, при создании ответа
Была такая мысль, но не очень хочется так поступать: поле текстовое и довольно немаленькое. И потом, итак избыточность БД чрезвычайно некислая получается...
 
M

morpheus

Для: LuMee
Условие выборки в представлении применима ТОЛЬКАО к документу, и усё... ни к профилю ни к респонсам никак, соответсвенно необзожимо в документе хранить ключи/фразы из респонсов
 
F

Fossil Code

Можно ли составить формулу отбора во вью таким образом, чтобы отбирались документы-ответы, удовлетворяющие определенным условиям, а также все родительские документы для выбранных ответов?
Или, как вариант, другой вопрос: можно ли сделать так, чтобы для ответов во вью отображать значения каких-то полей родителей? Здесь, понимаю, задача еще труднее... Лично мне ничего на ум, кроме @GetDocField(@ParentDocumentId; "SomeField"), не приходит, однако в столбце вью такое точно не заработает.

Сисемасиськи боролся с таким положением, пока не пришел к следующей технологии: при создании ответных документов, существенные атрибуты родительского документа наследуются в скрытые или открытые read-only поля. Это дает возможность строить категоризованные виды, которые фактически отражают иерархию родитель-ответ, но при этом пользуются механизмом ключевых общих полей. С такими видами гораздо удобнее работать, чем с родительскими-ответными. Это решает Ваш первый вопрос и, частично, второй.

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

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

LuMee

Сисемасиськи боролся с таким положением, пока не пришел к следующей технологии: при создании ответных документов, существенные атрибуты родительского документа наследуются в скрытые или открытые read-only поля. Это дает возможность строить категоризованные виды, которые фактически отражают иерархию родитель-ответ, но при этом пользуются механизмом ключевых общих полей. С такими видами гораздо удобнее работать, чем с родительскими-ответными. Это решает Ваш первый вопрос и, частично, второй.
Собственно, подобный подход я и использую, однако, у меня таких полей и так уже весьма и весьма немало. Результат - избыточность просто суровая.
Так, моя система является преемником более старой системы, основанной на реляционной БД (FoxPro). Помимо всего прочего, в мою систему из этой старой переносятся данные. Так 12Мбайтная "старая" база превращается в почти 50 Мбайт лотуса... Так что ввод каждого дублирующего поля меня расстраивает :lol: Но, по ходу, иного пути нет.
По второму вопросу, если поле велико, не хочется увеличивать избыточность, то есть контр-вопрос: а какова нужда это делать? Если у Вас есть вид, представляющий иерархию, то для строки родителя Вы запросто можете показать это поле в соотв. колонке (или формулой в универсальной колонке), а для всех его ответных и так все понятно в силу их "подчиненности". Т.е., при условии, что в виде представлена иерархия, зачем выводить в каждой строке вида для ответного документа одно и то же поле из родителя?
Проблема в том, что мне нужно отобрать лишь небольшую часть ответов, с которыми должно отобраться и того меньше родителей. Причем критерии отбора применяются именно к ответам. Вот если бы была в лотусе какая-нибудь формула типа @Parent (обратная по своей сути @AllChildren)...
Если же предложенное рассуждение для Вас неприемлемо, то всегда существует возможность вместо вида воспользоваться фолдером, а вместо формулы отбора -- скриптом, который этот фолдер наполнит линками в точности так, как Вы этого захотите.
Фолдер - идея хорошая, в свое время одной из первых пришла в мою голову, однако тут все жестоко упирается в производительность. Открываться такой фолдер будет достаточно часто и достаточно большим количеством народу сразу, так что обновление содержимого таких фолдеров заставит-таки сервер поперхнуться.

В общем, придется, видимо, вводить доп. атрибут и в очередной раз перекраивать базу (хорошо, хоть эта процедура в лотусе выполняется легко :))...
 
F

Fossil Code

Есть еще одна технология, и однажды, когда серверы были еще маленькими, т.е. стояли на рабочих станциях, ее попробовал, остался доволен, но просто железо (диск и скорость) заставило отказаться. Суть в применении полнотекстового поиска, (который нынче стал гораздо удобнее). Фиксированные и диалоговоые запросы вешаются на кнопки в виде. Естественно, от факта сохранения необходимой ключевой информации в документах не уйдешь. Это для отображения, для первоначального ввода -- можно по старинке, родитель-ответ.
 
Мы в соцсетях:

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