|
Notes |
|
|
(0000262)
|
|
Tikh
|
|
06-10-2010 06:42
|
|
Я предлагаю для этой цели переделать организацию хранения меток в программе.
Категории и подкатегории - это папки. Метки - это файлы, одна метка - один файл.
Структура категорий и меток в программе определяется структурой папок и файлов на диске в папке для хранения меток САС.Планеты. |
|
|
|
|
|
Где задавать видимость отдельных категорий и диапазон зумов для отображения? |
|
|
|
(0000266)
|
|
gpsMax
|
|
06-10-2010 18:25
|
|
Наверное, там же, где он сейчас задаётся. В sml файле/файлах, думаю. В интерфейсе - теми же галками и кнопками. Единственно, что если в категории часть объектов видима, а часть нет, то при её сворачивании, отображении одной строкой, галку надо ставить полузатемненную. Всё как обычно, как в стандартных виндовых интерфейсах.
Или я не так понял вопрос? |
|
|
|
(0000268)
|
|
Tikh
|
07-10-2010 04:44
(edited on: 07-10-2010 05:09) |
|
>Где задавать видимость отдельных категорий и диапазон зумов для отображения?
Если вопрос был мне, про моё предложение реорганизовать хранение меток, то я предлагаю хранить видимость и диапазон зумов в файле, который лежит в папке категории. Пустой файл с именем вида: "visible-8-24", или "invisible-8-12".
Это позволит управлять изменением видмости категорий с помощью внешних утилит или даже .bat файлов - путём консольной команды переименования.
Также, организация хранения меток в отдельных файлах позволит сразу же решить две проблемы, добавить две важные возможности, которые сейчас в SAS.Планете не реализованы и затруднена внешняя реализация:
1) Совместная работа в локальной сети
2) Разграничение доступа пользователям к разным категориям меток
Поясню:
1) Сейчас - кто первый встал, того и тапки. Первый запустивший в локальной сети SAS.Планету, блокирует на запись .sml файлы с метками и остальные не могут что-либо отредактировать, у них для чтения, пока первый пользователь не выйдет.
Если одна метка - один файл, то тогда все метки не блокируются, свободны для изменения, файл с меткой блокируется только на время открытия окна редактирования и до нажатия на кнопку "сохранить", которая производит запись изменений в конкретный файл.
Это позволит сразу многим пользователям в сети работать с SAS.Планетой, свободно создавать и редактировать метки.
2) Разграничение доступа к меткам. Сейчас нет никакой возможности ограничить некоторым людям доступ к определённой категории меток, а очень нужно. В SAS.Планете реализовать такой функционал - это трудоёмкий процесс и дополнительная задача для разработчиков.
Если же метки будут храниться в отдельных файлах и папках, то проблема отпадает сама собой - доступ распределяется средствами сетевого администрирования, администрирования пользователей Windows, доменных политик ЛВС и т.д.
То есть задача полностью ложится на системного администратора локальной сети, а для него настроить доступ пользователей к папкам и файлам не составит проблем.
Т.е. относительно небольшими усилиями на изменение в программе добавляется значительный функционал.
|
|
|
|
|
|
Ладно. Забудем на секунду о способе хранения меток и категорий. Опишите более подробно как должны влиять галочка видимости и диапазон зумов родительской категории на метки дочерних категорий. |
|
|
|
(0000278)
|
|
gpsMax
|
07-10-2010 08:05
(edited on: 07-10-2010 08:06) |
|
Тут есть два подхода. Можно считать (и реализовать в программе), что настройки категорий независимы друг от друга. А можно сделать стандартное виндовое поведение галок, которое можно "в природе" наблюдать многими способами, из которых в голову приходят, например, выбор вложенными галками компонентов программ в инсталляторах.
С первым подходом всё просто, изменение в любой категории ни на что более не влияет. А второй попробую описать поподробнее.
Для примера, возьмём, что есть категория с именем "1", являющаяся родительской, и есть категория "2", дочерняя, вложенная в родительскую.
1. Галочка видимости
Вначале, обе категории невидимы (надо же с чего-то начинать). Тыкаем в галку у двойки. У единицы появляется полупрозрачная галка, то есть какие-то члены категории видимы, а какие-то нет. Итого получается, что все члены категории 1 невидимы, за исключением входящих в 2.
Тыкаем в галку у двойки еще раз, снимая её. Поскольку у единицы сейчас все вложенные объекты стали невидимыми, то её галка исчезает. Смотрим на этот эффект и снова взводим двойку. Итого - то же самое, что было абзацем ранее.
Тыкаем теперь в единицу - это команда "снять/поставить галку и все дочерние". Получается либо обе галки стоят, либо обе сняты. Останавливаемся на стоящих.
Тыкаем в двойку и обращаем внимание, что родительская галка становится полупрозрачной. Как это, вроде ниже уровнем нет стоящих галок? Ан нет, первая галка остается стоящей, поскольку видимостью элементов, вложенных непосредственно в категорию 1, нельзя управлять из нижележащей категории 2, на то она и нижележащая. То есть в единичке галка остается стоять, хотя и затеняется.
2. Диапазон зумов
Тут всё несколько посложнее бинарной логики предыдущего пункта. Я предлагаю пойти проверенным путем и сделать логику майкрософтовской же модели, реализованной в файловой системе NTFS и в службе каталогов Active Directory. Всё очень просто:
1)Каждый нижележащий объект наследует настройки прав предыдущего, если установлена галка "наследовать". Если не установлена, то не наследует.
2)Каждый вышележащий объект может принудительно сбросить настройки прав нижележащих объектов, несмотря на галку из пункта 1, заменив их своими.
С этой моделью можно поиграться как на NTFS'ном разделе, создав папки и меняя у них права, так и на виндовом сервере с AD, случайно оказавшемся под рукой - всё точно так же, только чуть меняются имена галок.
Возвращаясь к нашим настройкам уровней видимости: каждой категории, помимо значений зума, потребуются две галки: что-нибудь типа "Наследовать родительские" и "Сбросить дочерние". Может показаться, что это майкрософтовское масштабирование здесь слишком сложно и громоздко, но на самом деле как раз без любой из этих галок будет немного неудобно.
Как работает: меняем уровни зума у категории с установленной галкой "Сбросить дочерние" - одновременно меняются и дочерние. Если же стоит галка "Наследовать родительские", то менять ничего не получится и для изменений надо лезть в родительскую папку.
|
|
|
|
|
|
Ну что ж, учитывая, что второй подход требует изменения в структуре данных, чего я делать не хочу, то будет первый подход. Тоесть настройки категории влияют только на точки принадлежащие непосредственно самой категории и не влияют на видимость объектов во вложенных категориях. |
|
|
|
(0000313)
|
|
gpsMax
|
|
12-10-2010 18:20
|
|
|
Настройки видимости изменений в структуре данных не потребуют. Тупо галки. Это с диапазоном зумов без изменений трудно обойтись, а галки видимости переделки sml не потребуют. |
|
|
|
|
|
Потребуют, в вашем предложении у галки должно быть три состояния Включена, Выключена и Унаследована, а в структуре забит булевский тип, у которого только 2 значения. Так что увы и ах, но не в ближайшие годы. |
|
|
|
(0000328)
|
|
gpsMax
|
|
13-10-2010 11:10
|
|
Я предлагал немного не так. Типа два - включена/выключена. Но при включении/выключении галки одновременно с этим включаются/выключаются галки для всех вложенных категорий. Вложенность же определяется динамически, из структуры категорий, а не из файла данных в готовом виде, поэтому менять его не потребуется.
Тупо рекурсия: при включении/выключении галки пробегаем по вложенным категориям и применяем эту же операцию на них.
|
|
|
|
|
|
sas_multicategories.png (31,226) 05-10-2010 15:23