Уфф! Разобрался, наконец, с внутренней структурой VIEW.
Теперь можно делать динамические View в любом кол-ве без предварительного описания. И, что самое главное, формировать их структуру «на лету», под конкретную задачу или запрос юзверя!
На днях напишу небольшой класс для реализации этого дела. Будет только одно
ограничение — работать будет ПОКА только с файлами, описанными явно в приложении. Т.е. — как обычно. Класс работы с динамическими файлами пока задерживается — дюже сложная штука «файл»! Намного сложнее GROUP/QUEUE/VIEW вместе взятых.
Вообще, если посмотреть, то VIEW — самая простая из приведенных выше конструкций. Но, зато, какая крутая! Прям как в пословице: «Мал золотник, да — дорог!» VIEW просто использует готовые внутренние структуры, которые уже сформированы FILE`ом.
!!!!!!!!
Если вы считаете, что данная затея — стоящая, то тогда один вопрос по реализации этого класса:
— Как лучше задавать описание структуры VIEW?
Есть два варианта:
MyView xViewClassType
1.
MyView.ViewHeader(PrimaryFile,<Filter>,<Order>)
MyView.Project(PRI:Field1,PRI:Field2)
MyView.Join(SEC:AccessKey,PRI:Field1,PRI:Field2)
MyView.End()
MyView.End()
2.
MyView.ViewHeader('PrimaryFile,<Filter>,<Order>')
MyView.Project('PRI:Field1,PRI:Field2')
MyView.Join('SEC:AccessKey,PRI:Field1,PRI:Field2')
MyView.End()
MyView.End()
Т.е., в первом варианте в качестве параметров задаются непосредственно файлы/ключи/поля. Во втором варианте задаются просто строки, в которых и описана структура View.
Первый вариант проще в реализации, но не такой гибкий как второй. Второй вариант — на порядок сложнее.
Да. И, естественно, с данной динамической View можно будет делать все то, что можно делать со статической:
MyView.ViewRef{PROP:Filter} = GLO:ViewFilter
MyView.ViewRef{PROP:Order} = '+PRI:Name,+PRI:Code'
Open(MyView.ViewRef)
Loop
Next(MyView.ViewRef); if ErrorCode() then Break.
.
Close(MyView.ViewRef)