0000137: Вложенные категории

Notes
(0000262) Tikh (reporter) 06-10-2010 06:42	Я предлагаю для этой цели переделать организацию хранения меток в программе. Категории и подкатегории - это папки. Метки - это файлы, одна метка - один файл. Структура категорий и меток в программе определяется структурой папок и файлов на диске в папке для хранения меток САС.Планеты.

(0000263) vdemidov (manager) 06-10-2010 07:29	Где задавать видимость отдельных категорий и диапазон зумов для отображения?

(0000266) gpsMax (manager) 06-10-2010 18:25	Наверное, там же, где он сейчас задаётся. В sml файле/файлах, думаю. В интерфейсе - теми же галками и кнопками. Единственно, что если в категории часть объектов видима, а часть нет, то при её сворачивании, отображении одной строкой, галку надо ставить полузатемненную. Всё как обычно, как в стандартных виндовых интерфейсах. Или я не так понял вопрос?

(0000268) Tikh (reporter) 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, доменных политик ЛВС и т.д. То есть задача полностью ложится на системного администратора локальной сети, а для него настроить доступ пользователей к папкам и файлам не составит проблем. Т.е. относительно небольшими усилиями на изменение в программе добавляется значительный функционал.

(0000272) vdemidov (manager) 07-10-2010 05:25	Ладно. Забудем на секунду о способе хранения меток и категорий. Опишите более подробно как должны влиять галочка видимости и диапазон зумов родительской категории на метки дочерних категорий.

(0000278) gpsMax (manager) 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, случайно оказавшемся под рукой - всё точно так же, только чуть меняются имена галок. Возвращаясь к нашим настройкам уровней видимости: каждой категории, помимо значений зума, потребуются две галки: что-нибудь типа "Наследовать родительские" и "Сбросить дочерние". Может показаться, что это майкрософтовское масштабирование здесь слишком сложно и громоздко, но на самом деле как раз без любой из этих галок будет немного неудобно. Как работает: меняем уровни зума у категории с установленной галкой "Сбросить дочерние" - одновременно меняются и дочерние. Если же стоит галка "Наследовать родительские", то менять ничего не получится и для изменений надо лезть в родительскую папку.

(0000279) vdemidov (manager) 07-10-2010 08:20	Ну что ж, учитывая, что второй подход требует изменения в структуре данных, чего я делать не хочу, то будет первый подход. Тоесть настройки категории влияют только на точки принадлежащие непосредственно самой категории и не влияют на видимость объектов во вложенных категориях.

(0000313) gpsMax (manager) 12-10-2010 18:20	Настройки видимости изменений в структуре данных не потребуют. Тупо галки. Это с диапазоном зумов без изменений трудно обойтись, а галки видимости переделки sml не потребуют.

(0000316) vdemidov (manager) 13-10-2010 05:08	Потребуют, в вашем предложении у галки должно быть три состояния Включена, Выключена и Унаследована, а в структуре забит булевский тип, у которого только 2 значения. Так что увы и ах, но не в ближайшие годы.

(0000328) gpsMax (manager) 13-10-2010 11:10 edited on: 13-10-2010 11:10	Я предлагал немного не так. Типа два - включена/выключена. Но при включении/выключении галки одновременно с этим включаются/выключаются галки для всех вложенных категорий. Вложенность же определяется динамически, из структуры категорий, а не из файла данных в готовом виде, поэтому менять его не потребуется. Тупо рекурсия: при включении/выключении галки пробегаем по вложенным категориям и применяем эту же операцию на них.

(0000330) vdemidov (manager) 13-10-2010 11:30	Хорошая идея. Спасибо.

Users who viewed this issue
User List	Anonymous (2833x)
Total Views	2833
Last View	23-04-2024 07:15

Issue History
Date Modified	Username	Field	Change
05-10-2010 15:23	gpsMax	New Issue
05-10-2010 15:23	gpsMax	File Added: sas_multicategories.png
06-10-2010 06:42	Tikh	Note Added: 0000262
06-10-2010 07:29	vdemidov	Note Added: 0000263
06-10-2010 18:25	gpsMax	Note Added: 0000266
07-10-2010 04:44	Tikh	Note Added: 0000268
07-10-2010 05:09	Tikh	Note Edited: 0000268	View Revisions
07-10-2010 05:25	vdemidov	Note Added: 0000272
07-10-2010 05:25	vdemidov	Assigned To	=> vdemidov
07-10-2010 05:25	vdemidov	Status	new => feedback
07-10-2010 08:05	gpsMax	Note Added: 0000278
07-10-2010 08:05	gpsMax	Status	feedback => assigned
07-10-2010 08:06	gpsMax	Note Edited: 0000278	View Revisions
07-10-2010 08:20	vdemidov	Note Added: 0000279
07-10-2010 08:20	vdemidov	Assigned To	vdemidov =>
07-10-2010 08:20	vdemidov	Status	assigned => acknowledged
07-10-2010 08:21	vdemidov	Target Version	=> 26xxxx
12-10-2010 18:20	gpsMax	Note Added: 0000313
13-10-2010 05:08	vdemidov	Note Added: 0000316
13-10-2010 11:10	gpsMax	Note Added: 0000328
13-10-2010 11:10	gpsMax	Note Edited: 0000328	View Revisions
13-10-2010 11:30	vdemidov	Note Added: 0000330
07-11-2010 19:36	gpsMax	Tag Attached: категории
10-03-2011 09:29	vdemidov	Status	acknowledged => resolved
10-03-2011 09:29	vdemidov	Fixed in Version	=> 101206
10-03-2011 09:29	vdemidov	Resolution	open => fixed
10-03-2011 09:29	vdemidov	Assigned To	=> vdemidov
10-03-2011 09:29	vdemidov	Target Version	26xxxx => 101206
06-04-2011 15:28	gpsMax	Relationship added	related to 0000055
07-04-2011 02:53	gpsMax	Relationship added	related to 0000304
24-04-2011 18:25	Tolik	Status	resolved => closed
21-07-2011 15:54	gpsMax	Relationship added	related to 0000878
21-07-2011 15:58	gpsMax	Relationship replaced	has duplicate 0000878
18-08-2011 04:09	gpsMax	Relationship added	related to 0000917
29-08-2011 03:59	gpsMax	Relationship added	has duplicate 0000948

SASGIS