Россыпь мелких вопросов

  • Автор темы Vagor.ini
  • Дата начала
P

proteam

Ребята, такой вот глупый вопрос... Как сделать чтобы представление автоматически обновлялось? Ну вот стоит там в настройках Index -> Automatic.
Просто вот пользователь открыл документ, сделал дело, теперь оно там не должно отображаться, а оно еще есть там. Можно открыть, ну конечно теперь он уже сделать ничего не может, но все равно, лишний раз не хочется показывать.
 

rinsk

Lotus Team
12.11.2009
1 155
126
BIT
38
хранил в XML, потом парсил его при открытии и сохранял заново при сохранении.
Можно я нарушу идилию про "парсинг"?:)
Вот накойфиг конфиг хранить в xml, который живет в базе? И накой нужен оверхед по памяти\времени выборки параметров из xml ? Представьте web App в котором 1000 юзеров считываю свой конфиг из хмл\джейсон.
в домино базе есть нормальный механизм реализации любого рода справочников.
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
42
в домино базе есть нормальный механизм реализации любого рода справочников.
А вот не надо так категорично:)
По сути, речь идёт (для плоского списка) о хранении List сущности (ключ - значение). Полезно, напр., для произвольного связывания доков (псевдо-парент\псевдо-чилдрен) с показом этой извращённой иерархии в view.
И это отнюдь не справочник.
Это, конечно, не про web разговор.
 

rinsk

Lotus Team
12.11.2009
1 155
126
BIT
38
По сути, речь идёт (для плоского списка) хранения List сущности (ключ - значение)
тем более - не понял роли xml в данном действии:)
с показом этой извращённой иерархии в view.
Показ во view имеет гораздо более ограничений, чем механизм хранения метаданных и имхо не является темой вопроса.
И это отнюдь не справочник.
Ну пусть ключ - значение не справочник, может я не до конца понял задачу, но хранить такое в xml, который имеет избыточность формата (для визуализации данных человеку) - эт перебор.
 

Leoric

Lotus Team
15.10.2003
69
10
BIT
83
Может я чего-то не понимаю.. но что мешает хранить пары ключ-значение просто в полях? С последующим обходом всех полей (если надо вся структура), либо обращением по имени поля, если оно известно?
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
42
не понял роли xml в данном действии
Так и было отмечено, что это не айс.
Только частный случай, что давно с успехом использую.
что мешает хранить пары ключ-значение просто в полях
Ни что не мешает. Только полЯ и одно поле - две большие разницы с точки зрения удобства использования, особенно при визуализации в классическом view.
 

Leoric

Lotus Team
15.10.2003
69
10
BIT
83
Так и было отмечено, что это не айс.Только частный случай, что давно с успехом использую.Ни что не мешает. Только полЯ и одно поле - две большие разницы с точки зрения удобства использования, особенно при визуализации в классическом view.
Хм, как раз для view кучка полей удобнее для визуализации, чем разбор на формулах текста из одного поля в разные колонки (да и индексеру существенно легче).

Опять же для указанной задачи 10 полей типа executor_RusName, executor_LNName, executor_... будут удобнее в плане добавления новых. Если еще и редактировать надо не программно, а пользователям то придется пилить логику по разбору на QO + обратному сбору на QS формы.

Если можно создать 1 документ на одну сущность, то ИМХА такой вариант предпочтителен. Если же в одну сущность надо впихивать инфу по десятку исполнителей, синхронизировать размерность полей и т.д. тогда уже удобнее велосипеды (XML, JSON, запись через тильду и т.п.).

P.S. Вариант работает если таких документов в день не надо создавать сотни тысяч, в таком варианте конечно уже надо думать в сторону хранения инфы в максимально "сжатом" в один док виде.
 

rinsk

Lotus Team
12.11.2009
1 155
126
BIT
38
Только полЯ и одно поле - две большие разницы с точки зрения удобства использования, особенно при визуализации в классическом view.
при десятках-двух параметрах вполне нормально живут "нумерованные" поля типа fied_n. и отображать их во вью просто через цикл. как то была мелкая задачка, в итоге между текстом в поле ключ-значение выбрал поле-n= значение - потому что надо было с ридерсами возится... типа такого (web View но не суть):
@If(@IsUnavailable(ReviewCount);@Return("[<b>Черновик</b>]");"");
n:=ReviewCount;
r:="";
th:="<tr>
<th>№</th>
<th>Роль</th>
<th>Статус</th>
<th>Подписал</th>
<th>Дата подписания</th>
</th>";
.....
@For(k:=1;k<=n;k:=k+1;
kk:=@Text(k);
Rrole:=@GetField("ReviewRole"+kk);
level:=@GetField("ReviewLevel"+kk);
rdata:=@GetField("ReviewData"+kk);
rstatus:=@GetField("ReviewStatus"+kk);
comment:=@GetField("ReviewComment"+kk);
comment:=@If(comment="";"";@NewLine+"<tr><td colspan=5 style='font-style:italic;color:"+@If(rstatus="3";"red";"green")+";'><b>"+comment+"</b></td></tr>");
img:="<img src=/"+@If(rstatus="";"icons/vwicn193.gif";rstatus="1";"icons/vwicn205.gif";rstatus="2";"icons/vwicn082.gif";rstatus="3";"icons/vwicn080.gif";"")+">";
rapprove:=@Name([CN];@GetField("ReviewApprove"+kk));
r:=r+@If(rstatus="-2";"";"<tr><td>"+img+"</td><td>"+level+"</td><td>"+rrole+"</td><td>"+rapprove+"</td><td>"+rdata+"</td><tr>"+comment+@NewLine)
);
"[<table id='reviewStatus'>"+flow+r+"</table>"+ex+exc+"</>"+lastrow+"]"
 
P

proteam

Как раз таки из-за не желания хранить все в XML я и спросил. Из опыта просто, может кто придумал какой то эффективный метод хранения.
при десятках-двух параметрах вполне нормально живут "нумерованные" поля типа fied_n. и отображать их во вью просто через цикл. как то была мелкая задачка, в итоге между текстом в поле ключ-значение выбрал поле-n= значение - потому что надо было с ридерсами возится...
ну как бы тут говорят что большое кол-во итоговых полей не есть хорошо
 
S

Shandrik

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

alexas1

Green Team
10.04.2014
1 202
225
BIT
42
Хм, как раз для view кучка полей удобнее для визуализации, чем разбор на формулах текста из одного поля в разные колонки (да и индексеру существенно легче).
Ты не понял идеи, я говорю о
с показом этой извращённой иерархии в view.
а это только одна (или 2) мультивалюйные колонки для категорий. В случае многих полей реализация или очень сложная или невозможна совсем (в классическом view). В хепагах такого нет - там всё элементарно с визуализацией.

Видел я такие реализации
А это кривые реализации - их надо уметь готовить;)
Связка парой юнидов parent\children не напрягает же?
И в чём здесь разница, кроме использования multivalue field?
 
  • Нравится
Реакции: Мыш
S

Shandrik

А это кривые реализации - их надо уметь готовить;)
Связка парой юнидов parent\children не напрягает же?
И в чём здесь разница, кроме использования multivalue field?

Это приём заshitного программирования. Но случай, если:
1. Сам забудешь про связанное поле
2. Твой преемник про связанное поле не знает
3. Сопровождающий горе-херург смарт-иконками поправил одно поле.
 
S

Shandrik

0. Если поменяется формат - у новых документов будут новые параметры, а у старых - нет.
 

rinsk

Lotus Team
12.11.2009
1 155
126
BIT
38
Лучче While до упора
не - там размерность полем ReviewCount задается.
И вообще - для того что бы чего-ть там не забыть - весь этот скоуп данных описывается в LS классе и манипуляции данными только через методы этого класса. при этом вообще без разницы в чем хранить метаданные - хоть в SQL. Чувствительно только UI отображение. для web уже не существенно...
 
  • Нравится
Реакции: Shandrik

alexas1

Green Team
10.04.2014
1 202
225
BIT
42
Это приём заshitного программирования. Но случай, если:
1. Сам забудешь про связанное поле
2. Твой преемник про связанное поле не знает
3. Сопровождающий горе-херург смарт-иконками поправил одно поле.
:) Достаточно написать в описалове: эта мегакрутая апликуха использует нестандартное связывание доков "многие ко многим", класс в библе "такой-то".
Хош пользуйся, хош нет.
И ващще, полез в чужой дизайн - думай, как курочишь.
 
Мы в соцсетях:

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