Здравствуйте, AlexandreVN, Вы писали:
G>>А я подумал что нужно что-то типа визуального редактора.... AVN>Так и есть. визуальный редактор справочников, шаблонов, модели документа и т.п.
Ну если это должен быть WYSIWYG редактор (типа MS Word). Тогда описанная мной выше схема подойдет. Хотя я не представляю как такое возможно в вебе.
Если это редактор свойств объектов, собранных в какую-то иерархию (как на рисунке), то вам понадобится отделить дерево (с картинками и надписями) от объектов. Всю работу с визуальным деревом можно возложить на стандартные котролы.
Здравствуйте, AlexandreVN, Вы писали:
AVN>я так понимаю — то что я привязался под конкретный интерфейс уже ошибка?
Конечно. Сегодня Вы хотите, чтобы объекты были доступны пользователю в виде дерева, завтра — в виде "табочек" и списка, послезавтра — в виде грида и т.д. Не стоит же каждый раз, как только у Вас поменяется GUI, изменять архитектуру!
Да и вообще всяких разных представлений может быть много. А вот внутреняя архитектура у Вас должна быть одна.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, AlexandreVN, Вы писали:
AVN>>я так понимаю — то что я привязался под конкретный интерфейс уже ошибка? КЛ>Конечно. Сегодня Вы хотите, чтобы объекты были доступны пользователю в виде дерева, завтра — в виде "табочек" и списка, послезавтра — в виде грида и т.д. Не стоит же каждый раз, как только у Вас поменяется GUI, изменять архитектуру!
КЛ>Да и вообще всяких разных представлений может быть много. А вот внутреняя архитектура у Вас должна быть одна.
а в случае если объект сам по себе логически подразумевает иерархическую структуру?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, AlexandreVN, Вы писали:
AVN>>а в случае если объект сам по себе логически подразумевает иерархическую структуру?
G>Например?
Здравствуйте, AlexandreVN, Вы писали:
AVN>а в случае если объект сам по себе логически подразумевает иерархическую структуру?
Структура (в том числе — иерархическая) создается под решение конкретной задачи. Например, для быстрого поиска используются деревья, хэш-таблицы, ячейки и т.д. Бывает, что модулю или программе нужно решать много всяких задач. Соответственно и структур (иерархических) может использоваться тоже много.
В общем, основная мысль такова: структура (ее еще можно называть классификацией) — далеко не абсолют. Поэтому ее лучше отделять от содержимого. Так для ускорения работы БД создаются всякие индексы, которые, на самом деле, тоже можно назвать в некотором роде иерархической структурой — ведь индексы задают другой способ упорядочения информации, которая хранится в БД.
Здравствуйте, AlexandreVN, Вы писали:
AVN>каталог товаров, дерево, тел. справочник и т.п.
Я надеюсь вы не собираетесь обрабатывать каталог товаров как дерево, где каждый узел может быть товаром или категорией (или другим классифицирующий признаком)?
Обычно товары и категории — разные объекты, хранятся и обрабатываются по-разному. При этом каждая категория содержит ссылки на товары, находящиеся в этой категории (а в БД наоборот — товар ссылается на категорию).
Дерево — абстрактный тип данных. А какая иерархия в телефонном справочнике вообще придумать не могу.
G>Я надеюсь вы не собираетесь обрабатывать каталог товаров как дерево, где каждый узел может быть товаром или категорией (или другим классифицирующий признаком)? G>Обычно товары и категории — разные объекты, хранятся и обрабатываются по-разному. При этом каждая категория содержит ссылки на товары, находящиеся в этой категории (а в БД наоборот — товар ссылается на категорию).
а почему нет? с помощью того же visitor
G>Дерево — абстрактный тип данных. А какая иерархия в телефонном справочнике вообще придумать не могу.
города — > первые буквы имени или округ-> вид организации (услуги) — > номера
да вообщем то неважно. может неудачный пример
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, AlexandreVN, Вы писали:
AVN>>а в случае если объект сам по себе логически подразумевает иерархическую структуру? КЛ>Структура (в том числе — иерархическая) создается под решение конкретной задачи. Например, для быстрого поиска используются деревья, хэш-таблицы, ячейки и т.д. Бывает, что модулю или программе нужно решать много всяких задач. Соответственно и структур (иерархических) может использоваться тоже много.
КЛ>В общем, основная мысль такова: структура (ее еще можно называть классификацией) — далеко не абсолют. Поэтому ее лучше отделять от содержимого. Так для ускорения работы БД создаются всякие индексы, которые, на самом деле, тоже можно назвать в некотором роде иерархической структурой — ведь индексы задают другой способ упорядочения информации, которая хранится в БД.
а что если под таким углом — есть объект для хранения объектов в дереве и неважно каких (есть только условие что все они должны обладать рядом свойств необходимых для построения дерева)?
Здравствуйте, AlexandreVN, Вы писали:
AVN>а что если под таким углом — есть объект для хранения объектов в дереве и неважно каких (есть только условие что все они должны обладать рядом свойств необходимых для построения дерева)?
Поисковый индекс.
Здравствуйте, AlexandreVN, Вы писали:
AVN>а что если под таким углом — есть объект для хранения объектов в дереве и неважно каких (есть только условие что все они должны обладать рядом свойств необходимых для построения дерева)?
Сферический конь в вакууме?
Вы слишком сильно зацикливаетесь на структурах данных.
Здравствуйте, AlexandreVN, Вы писали:
AVN>города — > первые буквы имени или округ-> вид организации (услуги) — > номера AVN>да вообщем то неважно. может неудачный пример
А позже Вам потребуются другие классификации:
по виду деятельности (не важно в каком городе);
по названию (опять-таки, не важно где);
по по номеру телефона;
по рейтингу, набранному среди Клиентов;
и т.д. — классификаций можно придумать множество.
Следует добавить, что одна и та же организация:
может предоставлять разные услуги;
находиться (иметь представительства) в разных регионах.
Что же теперь выходит — переделывать архитектуру программы каждый раз, когда появится новый критерий для классификации?
Разумнее, поступить по-другому — для каждого критерия создать свой индекс и хранить его отдельно. А архитектуру не завязывать на индексы.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, AlexandreVN, Вы писали:
AVN>>а что если под таким углом — есть объект для хранения объектов в дереве и неважно каких (есть только условие что все они должны обладать рядом свойств необходимых для построения дерева)?
G>Сферический конь в вакууме?
G>Вы слишком сильно зацикливаетесь на структурах данных.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, AlexandreVN, Вы писали:
AVN>>а что если под таким углом — есть объект для хранения объектов в дереве и неважно каких (есть только условие что все они должны обладать рядом свойств необходимых для построения дерева)? КЛ>Поисковый индекс.
Здравствуйте, AlexandreVN, Вы писали:
AVN>я запутался. что вы подразумеваете под индексами?
Любая классификация, фактически, и есть поисковый индекс. Если Вы пойдете в какую-нибудь крупную библиотеку, то увидите, что там есть, как минимум, два вида каталогов:
алфавитный — позволяет найти книгу по фамилиям авторов;
тематический — позволяет найти книгу по заданной теме.
Каталоги располагаются отдельно и не привязаны к объектам (книгам), т.е. в каталогах находятся не книги, а карточки (ссылки на книги). Сами же книги находятся в хранилище и заказываются по ссылкам из каталога.
Ваше дерево — это такой же каталог. Он должен содержать ссылки на объекты (например, их IDs), но не сами объекты, т.к. каталогов (индексов) можно наделать, сколько будет душе угодно.
